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.
