COLLECTED BUGS AND WISHES FROM THE FEBRUARY 2002 TRACE-FEST ART Memo 29 (Version 0) Colin Runciman, 1 March 2002 INTRODUCTION The February trace-fest was generally enjoyed and deemed successful. We had three visiting participants (Koen Klaessen, Ralf Hinze and Simon Thompson) who contributed both talks (QuickCheck, extensible indexed lists, refactoring) and programs (Recognize, Klausify, Frown and Tableau). Part of the success as the Fest was that it uncovered (or reminded us of) a number of bugs and prompted the expression of a large number of wishes for further development of the Hat tools. Here they are, listed separately as Bugs and Wishes for each of the Hat trace-viewing tools that we used (-explore, -observe and -detect) and finally for the Hat system as a whole. HAT-EXPLORE Bugs: * The = key. (1) It does not always give a result. (2) It sometimes gives a result which not in fully evaluated form. (3) Specifically, after termination with a run-time error, applying = to pending applications (SAT-B's) gives redex = redex not redex = _|_ as required * Display blanking. The upper part of the display is blanked when the current expression causes previous expressions to scroll upwards, and the topmost expression is not exactly at the start of the page. (Test case: trace back recursive calls of player' in Adjoxo.) * Indirections. Sometimes handled incorrectly? (Test case: Olaf to supply.) Wishes: * Unevaluated expressions. By default show as _ but with an option to show in full. * Interrupted evaluation. Distinguish this case from undefined. Display as redex = {interrupted} not redex = _|_. * Status/command line. At the bottom of the screen, a line for information such as 'no source reference', 'file not found' or 'hat-observe started'; also for completing multi-character commands. * Invoking hat-observe. o for all applications from the same source (requires hat-observe extension); O for all applications. [MAYBE: Click on a position in the source reference viewer to call hat-observe on a specific call site?] * The = key again. It should become an option toggle, rather than a one-off command. It should immediately apply to the current redex/equation, but not to previous ones => need to record a trail of toggle states. It should also make any newly displayed RHS the selected expr, or if a removed RHS contained the selection the selection should become whole LHS. * String and list navigation. [ and ] to become commands to move forward/backward to next/previous list element (implicit user claim that current selection is within a list). Former [ and ] rebound to { and }? * Controlling display precision. +n and -n to control precision of initial printing (like = these should take immediate effect on current redex/equation, but not previous ones). * Selection and sharing. There should always be exactly one selected expression, clearly indicated by a unique form of highlighting. [MAYBE: options to show sharing (1) in same redex/equation, or (2) everywhere, by a different form of highlighting.] * Dependent source browsers. Should be closed when user quits hat-explore. Could usefully allow scrolling to see wider context. [MAYBE ONE DAY: extend source highlight to show entire expression or definition, not just its starting point.] HAT-OBSERVE Bugs: * Premature termination. When invoked from other tools hat-observe terminates if there are no observations found. Should offer interactive use. * Counted applications. Counts of "unique most general" applications are not useful; abolish the c(ount) command! (But see wish for i/I command below.) * Bogus reductions. Sometimes equations with identical LHS and RHS are shown: eg. observe reduceAll in TableauRefac v.3. (May be a problem of unknown arities and partial applications, more easily fixed with the new .hat format.) * Application of the same function to two (separate but?) identical cyclic structures causes an infinite loop because of processing to find unique most general representatives. Wishes: * Show/Info. (1) s to be renamed i. (2) the i command should also show for each listed name a count SAT-C (+ SAT-B): eg. 173 (+ 2), or 0 (+ 3), but simplifying 64 (+ 0) to 64 and discarding items with 0 (+ 0) counts * Patterns/equations after 'in'. Permit a pattern and/or equation on the RHS of 'in'. For example, observe f _ = True in g _ = False. (At least don't silently fail for such patterns/equations!) * Observing constructors. Should be possible -- for example, to check invariants respected. Corollaries: (1) hat-observe should also have an = toggle which is always toggled off for constructor observations (and restored to its previous state afterwards); (2) there should be a command analogous to i for constructors (an I command would be mnemonic because of the upper-case convention for constructors). * Local observations. There could be an option (with suitable warning) to include locally-defined names among the observables. Not all depend on free variables anyway. Locals should perhaps be tagged in some way in the i listings (name in { }?). [MAYBE ONE DAY: support full observation of locals with context of free-variable bindings in .hat file. Add refs to static parent names in local name nodes; extend local argument lists to include free variables defined within top-level parent's (and name entries for these variables).] * Blocks of observations. The prompt after the end of a block of observations should be simplified to an overwritable status line "more? (y/n)" or similar. * Interruptable observations. It should be possible to interrupt or cut short observation lists before the end of an observation block is reached, without halting hat-observe itself: otherwise the user may be stuck with a lengthy and fruitless wait. A simple overwritable status line could be "searching ... (^C to stop)". * Families of bservations. [MAYBE: option to group observations with a common source for the application?] * Option status. A command to show the equivalent of hat-explore's permanent status line for options. * Separated observations. The user may want to observe each separate application (rather than unique most general representatives) because different applications have different contexts (if explored) and/or may have different unevaluated expressions beneath _'s. (The 'xu' flag is an unsafe and incomplete solution: it is not a first-class option and needs arity info to be correct.) HAT-DETECT Bugs: * If hat-detect is called from another tool, and it does not find a bug, it terminates and the window disappears immediately. * hat-detect does not find calls to untrusted functions within trusted functions unless they are reachable from SAT for the trusted application. (Eg. calls of a filter predicate.) Fix requires a linear scan to find relevant untrusted applications, assuming accurate trustedness info in the .hat file -- Olaf says it should be "perfect" using the new portable transformation! * hat-detect does not work for interrupted or failing computations. The new .hat format will make it easy to remedy this defect, but meanwhile a linear search could again provide a solution. Wishes: * A free navigation mode, to browse the full call-graph of the computation. As a small start: a command to list the immediate EDT children of the current equation. HAT IN GENERAL Bugs: * Haskell 98 gaps or bitterness: n+k, comprehensions, do-notation, etc. Wishes: * Merge pretty-printers for all tools to ensure consistency. * Put arity information into .hat files (even before new format)? * Make command syntax of tools as uniform as possible -- common subset with disjoint extensions in similar style? Consider using ':' as a prefix for multi-character or major-effect commands. * All tools to support changes in width of display window (ideally with automatic response, but at least after :resize). * A tutorial with examples to help introduce beginners to the tools and to explain the intuition or strategy behind choice of tools. * Tools should compare creation/modification times of sources, executable, trace and recorded output, and warn of apparent anachronisms. * CAFs defined by higher-order expressions such as composition chains do not trace nicely (eg. one has to 'observe' inner calls before one can 'explore' them -- and even 'observe' may not reach them). Also, trusted CAFS (eg. Prelude functions such as reverse) give only the single observation of the CAF reduction, not applications. [MAYBE: de-CAF Prelude functions? Introduce "quasi-trusted" functions such as composition? (Cannot just make it untrusted or else all compositions within the Prelude would be recorded too.)] * A "hat" tool that co-ordinates calls of specialised tools and keeps track of dependent windows etc. * [MAYBE: Readline functionality in command-based tools.] * Some people would like to animate reductions forwards rather than trace them backwards. [MAYBE ONE DAY: hat-animate when we have the new .hat format.] * Further tools for call-graph, data-flow and black-hole tracing. * Even faster construction of traces.