Hi Malcolm, Sorry I didn't get back earlier. I wasn't on the Hat mailing list until recently.
I discovered that hat doesn't like it if I define a type called "List", as in:
data List = List deriving Show main = print List
My guess is that all imports of Hat's special libraries should be qualified imports.
Yes, and they already are. The problem in this instance is that the transformed Hat.Prelude is re-exporting Fun, List, Tuple0, etc, when there is no need (they will always be available qualified from elsewhere anyway). Unfortunately, the untransformed equivalents ([],(,),(->)) which give rise to them /do/ need to appear in the export list of the untransformed Prelude. So there is no immediate and easy solution to this issue.
I see. But couldn't you just hide those things? ie: import Hat.Prelude hiding (List, Tuple... , Fun)
Another problem I have encounterd is that the trace tools exit leaving my terminal in a bad state, namely my terminal does not echo its output any more. I have to type "reset" at the prompt to get it back. This is on Debian linux with the gnome terminal.
We also use linux (Slackware) with the gnome-terminal. As far as I am aware, the terminal should be left OK provided the browser exited normally. If the browser crashes for any reason, it can leave the terminal settings badly. Are you exiting with a :quit command?
It seems that the problem only happens for me with hat-trail. hat-observe does not cause the same thing to occur. I use :q in both cases to quit. I'm using gnome-terminal version 1.4.0.6 I had the same trouble with the readline replacement that comes with GHC: System.Console.SimpleLineEditor which may very well be the editor that hat uses?
A small gripe is with the extra files that hat puts in the current working directory. My preference would be to put everything in the Hat subdirectory. Perhaps there is an option to do this?
Do you mean the .hat, .hat.output, and .hat.bridge files? We could add an option to place them in another directory I suppose.
Yes those files, and .hx if possible. Its a minor issue.
A more general comment is with the display of functional values.
The controversy (purely between the developers, of course) is whether it is useful to show anything in place of the lambda (\...) symbol. What would you show - the source code? a mapping?
Yes, either. Its nice to have the option of both.
* In principle, given a source reference attached to the lambda in the trace itself, the browser could "snip out" the full original source expression and insert it into the display. (We currently only have the source start position, not the full extent of the expression, but we hope to fix that eventually.)
But the source code display is already available! (by using a :source command to open a window with the relevant expression highlighted).
The value of free (lambda bound) vars inside the expression is not available this way, it may be useful to see them. Probably in the hat tools you can get at them via some other route. Perhaps you can record a link to the free vars for the lambda expression in the trail?
* You suggest an "observe"-like mapping as an extensional representation of the anonymous function. For one thing, such a mapping could be extremely large. And for another, it should in principle already be available, by a direct link to hat-observe.
It could be large, yes, but so could any value. I think you have to deal with large things anyway, so functions don't make the problem any worse than it already is. For declarative debugging, which is the realm of hat-detect, it is very important to be able to view all higher-order arguments and results, including anonymous functions. Some questions from the debugger can't be answered without this information. My general impression from playing around with this in buddha is that term representations of functional values are okay for simple partial applications and lambda expressions, but for anything else the only comprehensible thing is the map representation. Consider debugging a parser combinator library which is written in monadic style. Underneath each (non-trivial) parser is a mess of lambda abstractions and calls to >>=. You can print this stuff out, but few programmers will have any idea what it all means. The cognitive load is much too high. I think in this situation it is nicer to see the parsers as mappings from inputs to outputs. Thanks for your answers to my questions. Cheers, Bernie.