[Hat] Program Compiles With GHC 6.6 but not Hat

[Tom Cooper]

Olaf said:


>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.