[Hat] Program Compiles With GHC 6.6 but not Hat

[Tom Cooper]

This is caused by a limitation of Hat: Hat cannot handle defaulting of
numeric classes.

<snip>

In real programs we have hardly ever come across uses of defaulting.
Ciao,
Olaf

Malcolm said:

* Implementing type inference is difficult enough that we did not
consider the effort worthwhile for the tiny benefit of being able to
handle defaulting.

Bernie said:

a slightly inconvenient problem

These assessments depend very much on your point of view.

The only proper program I have tried to use hat on required rewriting to
get hat to understand it. The program was only ~2k lines of code, and
there were 3 different idiosyncrasies of hat which gave problems. The
defaulting idiosyncrasy was one of them. I imagine that most people that
try hat find it won't understand their code, and give up on it
immediately. I am therefore skeptical that this is hardly ever a problem
for people even if you 'hardly ever come across' it.

I don't remember reading, when I downloaded hat, that it was a beta
version, or that I would need to change my code in order for hat to work on
it, let alone a systematic description of the changes I would have to
make. This made it very difficult to understand the problems I was having,
and used a lot of my time, and some other people's too.

These three idiosyncrasies, if I recall correctly, required ~20 unwanted
changes in my code, so I made a hat version of my code with these
alterations, but it is very difficult to keep two parallel versions of a
piece of code up to date with each other. For this reason, I didn't find
it 'a slightly inconvenient problem'.

The existence of a decent debugger/tracer makes a significant difference to
the utility of a language; particularly, I think, a lazy language, because
the cryptic evaluation order makes print statements in the code less
informative.

I recently gave a presentation about haskell at my work, and had to
significantly tone-down the strength of my recommendation of it because I
find haskell code so difficult to debug. At work we use windows (as I do
at home), and despite Neil Mitchell's efforts, not enough of the hat tools
have been converted to windows to make it worth using them. I didn't find
the instructions for using hat via cygwin sufficient for someone with my
low level of expertise.

It is my personal belief that the lack of a powerful debugger/tracer that
works 'straight out of the box', is the major constraint preventing the
widespread adoption of haskell.

I have no idea how difficult it would be to make hat work on all valid
haskell98 code 'out of the box', on windows as well as unix, so I can't
criticize anyone for the fact that it doesn't. However, I am strongly
opposed the point of view that, for whatever reason, this doesn't really
matter.

Hat is free to use, and because of this, I feel I shouldn't be whining
about problems with it. However, I feel that descriptions of Hat, for
example in the communities and activities report, or on the hat website,
should contain prominent and frank statements about its current
limitations. I feel this is only fair to the readers who are otherwise
likely to waste a significant amount of time on hat before they get
disillusioned.

Tom.

[Neil Mitchell]

Hi Tom,

Post by Tom Cooper
These assessments depend very much on your point of view.

With infinite resources I'm sure all these things would get fixed.
Unfortunately infinite resources is not something Hat has... Without
infinite resources, you have to prioritise. If Hat was being developed
by a commercial company, I am sure more focus would be directed
towards graphical tools and fixing the small issues to give something
more polished. Unfortunately in academia those things won't make a
paper, win any research grants, and are harder to get done.

That fact that the goal posts for Haskell keep getting moved also
makes this a much harder task!

Post by Tom Cooper
and
there were 3 different idiosyncrasies of hat which gave problems. The
defaulting idiosyncrasy was one of them.

Please list all 3 of them.

Post by Tom Cooper
I imagine that most people that
try hat find it won't understand their code, and give up on it
immediately. I am therefore skeptical that this is hardly ever a problem
for people even if you 'hardly ever come across' it.

I don't use Hat because every time I've tried to use it I get to the
point where it's easier to insert trace calls than work round whatever
particular reason Hat is failing for now.

Post by Tom Cooper
I recently gave a presentation about haskell at my work, and had to
significantly tone-down the strength of my recommendation of it because I
find haskell code so difficult to debug. At work we use windows (as I do
at home), and despite Neil Mitchell's efforts, not enough of the hat tools
have been converted to windows to make it worth using them.

If the Hat tools all worked on Windows, would that change your
assessment of Hat? Would that convince you to use it? Because I don't
use Hat, that makes me less inclined to spend too much effort porting
the tools. Personally, even with all the tools available on Windows, I
still wouldn't use Hat because of the unreliability of generating
traces.

Post by Tom Cooper
I didn't find
the instructions for using hat via cygwin sufficient for someone with my
low level of expertise.

If debugging Haskell is to painful as to have to use cygwin, just
rewrite your application in C# and use the great debugger included
with Visual Studio :)

Post by Tom Cooper
I have no idea how difficult it would be to make hat work on all valid
haskell98 code 'out of the box', on windows as well as unix, so I can't
criticize anyone for the fact that it doesn't. However, I am strongly
opposed the point of view that, for whatever reason, this doesn't really
matter.

I have a plan to get this going using Yhc.Core. The problem would be
that its a different version of the code, based on your original, but
the user would have to brain hop between their original code and the
code being debugged. Having worked with Yhc.Core plenty, my brain does
this hopping automatically, but I suspect that it won't be fun for
other people - but should be very reliable.

Thanks

Neil

[Colin Runciman]

Tom,

Thanks for reporting your Hat experience, albeit a negative one. For
those of us who use Hat regularly, and get the results we need, it is
easy to forget the problems that new users may face.

Post by Tom Cooper
The only proper program I have tried to use hat on required rewriting
to get hat to understand it. The program was only ~2k lines of code,
and there were 3 different idiosyncrasies of hat which gave problems.
The defaulting idiosyncrasy was one of them.

It would be very helpful to know what the other problems were, apart
from default numeric types.

Post by Tom Cooper
These three idiosyncrasies, if I recall correctly, required ~20
unwanted changes in my code, so I made a hat version of my code with
these alterations, but it is very difficult to keep two parallel
versions of a piece of code up to date with each other. For this
reason, I didn't find it 'a slightly inconvenient problem'.

I quite agree that maintaining parallel versions is a pain, and should
be unnecessary.

Post by Tom Cooper
It is my personal belief that the lack of a powerful debugger/tracer
that works 'straight out of the box', is the major constraint
preventing the widespread adoption of haskell.

You may well be right. Those of us who developed Hat had the aim that
it would indeed work 'straight out of the box' for any Haskell 98
program. It is clear that we have fallen short of that aim, and it is
useful to have reports such as yours. We'd like to fix whatever problems
prevent people from using Hat on their Haskell 98 programs.

Post by Tom Cooper
Hat is free to use, and because of this, I feel I shouldn't be whining
about problems with it. However, I feel that descriptions of Hat, for
example in the communities and activities report, or on the hat
website, should contain prominent and frank statements about its
current limitations.

As I say, your report of problems is welcome and helpful. As to the
need for prominent and frank statements about limitations, these are
already provided. One link from the main Hat web page is to the Bugs and
Limitations page. But if you think there are further limitations that
should be added to the list, do tell us.

Regards
Colin Runciman