Hat bugs, wishes and comments noted during Freiburg trip 15-17 May
------------------------------------------------------------------

BUGS:

* hmake -hat cannot cope with literate files

* Inconsistently hmake calls nhc98 with its full path but hat-trans
  without a path; it is unclear if a specific or the version in the
  current PATH should be chosen.

* An empty export list causes hat-trans to abort with
  "non-exhaustive pattern in case, AuxFile line 390".

* Hat-trans sometimes transforms pattern bindings with newtype data 
  constructor incorrectly, duplicating variable definitions.
  Example: instance Monad TI ... in type checker
  Error already in renaming phase (-tracefns shows wrong result).

* Observing bestOf in Adjoxo after interruption shows many unevaluated
  arguments. _ should be shown. Maybe cause is that Forward nodes are
  not marked as unevaluated?

* Could not call any tool from the other. New window disappears immediately.
  Could the new window at least stay so that any error message can
  be read?

* hat-observe tiBindGroup hangs after 2 equations. I suspect this is the
  Hidden-Forward chain loop that was fixed.

* Module system still not correctly implemented. Multiplication.hs with
  Wash reports that aName is not visible and sName is ambiguous.

* In nhc98 (not Hat) bug in import mechanism. For
    import List hiding (init)
    import qualified List (init)
  identifier List.init is not visible (example Persistent2.hs)

WISHES:

* A new viewing tool for free navigation through the EDT.
  In particular it is much easier to spot a faulty node than confirm
  the correctness of one. Is it possible to display one node with
  all children?

* Locally defined variables should be freely viewable in all tools.
  This even without bindings of free variables, although that is
  also desirable.

* Strings are often displayed far to short. Could the cut-off depth 
  for strings be separated from the cut-off depth of other expressions?

* Display lambda expressions in full (possibly only expanded on demand).

* It might be nice to see functional values as mappings, as in Hood,
  instead of variables, partial applications and lambdas. In particular,
  if a result is a monad. "TI (\..)" is not a very helpful result.

* Could there be a way to see the "result" of a monad? Note that the
  result is only part of the monadic value; cf. state monads.

* Programs contain many monads and higher-order combinators. They need
  to be supported better in some way.

* More freedom in hat-trail: do not always want to start at last parent,
  want to go to end of parent chain below a given parent.
  Example: type checker, want to go back to render to see chain of
  functions ($).

* Need better support for viewing parts of function compositions 
  (.) or ($).

* Can there be again a hat-trail with graphical user interface? In 
  particular selection of expressions was much easier there.

* How to use Hat without hmake but one's own Makefile? Is it easy to
  adapt the Makefile?

* Enquire why hat-trans is currently very slow on StdPrel.hs of the type
  checker. What is the bottleneck? 

* It is irritating to see strings such as ""Hello"". Maybe characters
  should be escaped, e.g. "\"Hello\"".

* When entering : commands in tools backspace should work.

* hmake (nothing to do with Hat): it should allow in each directory 
  a file with options for the various source files.

COMMENTS:

* The slowdown of self-tracing programs considered irrelevant, because
  Hat assists locating bugs that can hardly be found otherwise. So in
  total Hat reduces the time for locating a bug, in particular the
  programmer's time. Also many large and complex programs do not run long
  before they expose the bug.

* Did not like Hood because writing of instances is simple but considerable
  amount of work.

* Hat-detect: Tried, but large and hard to anwer questions were daunting.

* Question: for which other kinds of programming languages is the
  Hat tracing and viewing model suitable?

* Trace recording over the network is incredibly slow. Is the trace really 
  written through a buffer or does a lot of synchronisation happen that
  could be avoided?

* Lack of defaulting required two type annotations in Type.hs of the type
  checker.