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.