THE AFP SUMMER SCHOOL HAT WISH LIST
ART Memo 33 (Version 0)
Colin Runciman, 29 August 2002

Here is a list of the bugs, requests and suggestions from Summer School
participants after they had used Hat.  Some of these are already
known to us, but it is still interesting to note that they are
raised by users; others are new.

1. The hat tools should quit cleanly if there is no .hat file.
   
   (A common mistake was to try to combine run-time and trace-time
   in a command such as "$ hat-something Prog < input" --- perhaps
   there is scope for a simple hat script here.)

2. Can the hat-* tools be modified to recognise incomplete .hat
   files still in the process of being computed, and allow them
   to be examined?  For example, hat-observe would report on the
   recorded applications *so far*, and hat-trail could start with
   the last recorded application.  It should also be possible to
   refresh/reload during a session to reflect a more complete
   trace.
   
   (I imagine this would not be too difficult.  Incomplete .hat
   files may of course contain trace references beyond the current
   end of the file --- to nodes yet to be flushed from the trace
   buffer --- but these might be shown as {?} or similar.)
   
3. Would it be possible to run a program untraced until an event
   of interest occurred, and then switch to a traced evaluation,
   or request a traced evaluation in addition to the normal one?
  
   (This should be feasible by linking both traced and untraced
   modules in a single binary, defining wrappers to lift ordinary
   values into traced values with a special constant trace ref,
   and hence a "traced apply" operator. One immediate application
   would be untraced testing with QuickCheck until a failing case
   occurs, which is immediately reevaluated with tracing --- we
   could assume that the body-predicate of a property is defined
   as a named top-level function.  More generally, there would be
   applications to any long-running computation for which constant
   tracing would be too costly.)
   
4. Can there be more support for modules at trace-viewing time?
   For example, observable names could be listed by module
   in :info tables, with module headings also indicating which
   modules are trusted.  Qualified names could be supported in
   queries, and there could be options to display expressions
   using qualified names. Also, could there be a way to specify
   that an untrusted module is to be treated as trusted at
   trace-viewing time.
   
5. Colour discrimination depends on the individual.  How about
   options to set the different highlighting colours?
   
Specific to hat-observe:

6. Locally defined names should be listed (optionally?)
   by :info under their syntactic parents.  Also, some notation
   is needed (similar to a qualified name) to refer to locals
   unambiguously in queries.
   
7. Patterns involving infix operators should match correctly
   even when this depends on precedence and associativity.
   
Specific to hat-trail:

8. How about a way to step forwards, rather than backwards, in
   the trail?
   
   (There is clearly continuing demand for this controversial
   feature :-).  What we need is a simple definition of the result
   of a forward step: it only makes sense for outermost left-hand-side
   expressions, since all others are already displayed in their most
   evaluated form anyway; and we don't have the information to generate
   a full instance of the defining body, even if that was desirable.)
   
9. When hat-trail is invoked by :t from hat-observe, the initial
   display should be an equation exactly if the hat-observe context
   was an equation.
   
   (Fair point; more generally, the sense of integration could be
   improved by carrying across options such as cutoff depth, and
   other options such as :set recursive off could have sensible
   interpretations in hat-trail too.)