[Hat] comments on hat 2.02

Bernard James POPE bjpop at cs.mu.OZ.AU
Thu Mar 4 20:25:33 EST 2004


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.


More information about the Hat mailing list