
Hi all, I've been playing with hat 2.02 installed via a debian package. Using ghc 6.02 (I think) to build the transformed code. (Note: I couldn't get it to build on my own with ghc 6.02). I'm not sure if my version has all the latest patches applied to it (somehow I doubt it). I apologise in advance if my comments are covered in the documentation. (I looked, but I didn't see them). 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 When ghc tries to compile the transformed code it finds that my List type clashes with one that's coming via the Hat.Prelude. I found that the problem is fixed if I do this in Hat/F.hs: import Hat.Prelude hiding (List, aList) Obviously this is not a general solution. My guess is that all imports of Hat's special libraries should be qualified imports. 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. 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? A more general comment is with the display of functional values. The item: 1. option to show lambda expressions in full appears under the heading "Controversial Wishes". I wonder what it means to be controversial in this case? My general experience with buddha is that term-based representations of functional values are ok when they are small things like partial applications, such as: map (+1) [1,2,3] = [2,3,4] But when the function is a complex thing, such as a nested lambda it can get far too difficult to understand. This occurs a lot in certain styles of programming, like parser libraries (which can be very hard to debug). Generally, I've found that with complicated functions it is much nicer to see them as partial maps, like the way that observe shows functions: map {1 -> 2, 2 -> 3, 3 -> 4} [1,2,3] = [2,3,4] Is it possible to do the same in Hat? One last question is will hat-detect be released again? Cheers, Bernie.

Bernard James POPE
I've been playing with hat 2.02 installed via a debian package. Using ghc 6.02 (I think) to build the transformed code. (Note: I couldn't get it to build on my own with ghc 6.02).
Yes, the original tarball of 2.02 needs a bunch of patches to get it to compile with ghc-6.2. We hope to release a new version 2.04 in the relatively near future to solve those issues, and also incorporate numerous other small bugfixes and enhancements. If you want to play with the current CVS version, do feel free. It is available from cvs.haskell.org.
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
When ghc tries to compile the transformed code it finds that my List type clashes with one that's coming via the Hat.Prelude.
Hmmm, yes there are a few types and constructors that fall into this category. You are right, they are not currently documented. They are: Fun(Fun) List(Cons,List) Tuple0(Tuple0) ... Tuple15(Tuple15) Interestingly, nhc98 does not complain, even though the usage you show is indeed technically ambiguous.
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.
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? Hat-trail issues stty -icanon min 1 -echo on entry and stty icanon echo to reset on exit.
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.
A more general comment is with the display of functional values. The item: 1. option to show lambda expressions in full appears under the heading "Controversial Wishes". I wonder what it means to be controversial in this case?
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? * 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). * 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. The fact that there is currently no actual mechanism to pass the particular lambda to hat-observe is something we would definitely like to fix. But the controversy would be about whether to encourage the user to jump between browsers, or to "in-line" the results of hat-observe into the display of another browser instance.
One last question is will hat-detect be released again?
Yes, it will. An incomplete version of hat-detect is currently sitting in CVS, but it still requires some work to its user-interface before it can be released properly. There is also the prospect that we might release some new browsers, based on work by undergraduates. hat-anim animates the reduction of expressions, and black-hat detects the program cycle leading to a black hole. Regards, Malcolm
participants (2)
-
Bernard James POPE
-
Malcolm Wallace