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.
