Hi Pete,

This will let the user search though all the functions called, and see that function.s inputs and output. The UI will be based on that of JuK, with searching using haskell.s pattern matching syntax. Is this not just hat-observe?

A step over debugger for do blocks. This will be similar to normal debuggers Is this intended to be a brand new debugging tool?

Ethereal is a tool for examining network traffic, and my plan is to . borrow from it's "follow TCP stream" feature, which shows you all the traffic in a stream, and lets you see messages and replies. It will show text moving in and out of handles, and display the logical time between messages. So will this tool be an IO monitor? i.e. seeing all external actions which occur, and in what order?

This will allow the user to see how redexes happen and allow the use to see laziness in action. This will be based on hat-amin. It is dependent on writing a good graph drawing function. I think this will probably be more like a tree than a graph? If so its not that hard to do, lots of algorithms exist and they are pretty easy.

algorithmic

This will be a normal algorithmic debugger, though I haven.t thought of how it will work in a GUI. I had a design for this, basically a list of alternating question answer lines:

sort [] = [] <yes> <no> insert [] = [] <yes> <no> When a user clicks on a yes or a no which is at the bottom line, it generates a new question, when a user clicks on a yes or a no higher up, and different from the previous answer, it deletes the list below that point and generates a new question. This lets the user see their "choice history", and change it at any time, will being an essentially linear process for those people who don't want any additional complexity.

Any suggestions, comments? black-hat, hat-nonterm? Both are pretty trivial to integrate into a GUI, so it shouldn't be more than a few hours work. I would actually suggest doing these two first, just to figure out how to attack this on an easy problem.

One general point is that you seem to be proposing some new tools here? ethereal, monad, redex. Implementing a new tool is likely to take a lot longer than just guifying an existing one. You also might be biting off more than you can chew with that many new tools. (of course, if you can do it all, thats great!) I am looking forward to using hat-gui as a real debugging tool! Thanks, Neil

On 28 Jul 2006, at 17:59, Peter Nuttall wrote:

Hello all,

I'm doing my dissertation on writing a GUI for hat, and Neil Mitchell suggested I send a mail saying what i was planning to see if you guys had any good ideas or comments. This is the proposal:

The problem

Hat provides a easy way to generate a trace, and various tools have been developed to examine the traces produced by it. However, these tools have two main flaws: They are hard to learn and use and they are not linked together. Ideally we would like hat to be as easy to use as possible. This way it can both be used to debug real programs by Haskell programmers, but can be used as a teaching tool for beginners, so they can see how lazy evaluation works and find simple bugs when they write their first programs.

The solution

Write a graphical user interface to Hat. A clickable GUI will be easier to use than a ncurses GUI, and will seem easier to use. The GUI will provide the same functionality as the hat tools do already, but it will be easier to use. This will be done by separating out the current user interface from the functionality as much as possible, then making the functionality into a library. As part of this, I will try and upgrade the tools to use the new tracing library written by Tom Shackell.

The GUI's will be implemented in GTK2HS . It will consist of a Window with tabs for each tool. Neil Mitchell has already constructed a GUI, and I plan to use this as a starting point.

The tools that will be usable though the GUI will be:

Search

This will let the user search though all the functions called, and see that function.s inputs and output. The UI will be based on that of JuK, with searching using haskell.s pattern matching syntax. As Neil said, this sounds a lot like hat-observe

Monad

A step over debugger for do blocks. This will be similar to normal debuggers An excellent idea, but I think you might have a few problems, I've had a look at trying to deal with IO actions a bit better and found that (actually quite reasonably) the trace doesn't actually have any information on what IO happened. The trace represents the purely functional part of the computation, so all you will see is that something evaluated to an IO action.

What I had considered doing is essentially emulating the IO actions in the tool, this is limited in the sense of it supports only those actions you code into the tool, but it is at least a solution. I'd be interested to see what you come up with here.

Stack.

When loading a a trace that has terminated with an error, the GUI will show a listing of the last functions called and their inputs and outputs. It will collapse any loops. Something similar to hat-stack?

Cover

It will use hs-colour to try and show which functions are being used for a set of inputs. If the new tracing library is used, and it supports taking the union of traces, this will be used to show coverage from lots of traces. This can be tied into quickcheck. Excellent, that's a really useful tool for me. You might find some useful code in hat-delta and in hat-cover. Hat-cover contains code that will give you full coverage for a call, while hat-delta contains code that will generate the coverage in the top level function call.

Ethereal bit.

Ethereal is a tool for examining network traffic, and my plan is to . borrow from it's "follow TCP stream" feature, which shows you all the traffic in a stream, and lets you see messages and replies. It will show text moving in and out of handles, and display the logical time between messages. Interesting - I'd like to see this integrated with your IO monad tool.

Display bit.

This will allow the user to see how redexes happen and allow the use to see laziness in action. This will be based on hat-amin. It is dependent on writing a good graph drawing function. So you want to do hat-anim but rather than showing the redex you want to show the current heap state? That sounds fun, but probably complex.

algorithmic

This will be a normal algorithmic debugger, though I haven.t thought of how it will work in a GUI. I'd thought about doing it the way neil suggests, but there are other

Straight off the top of my head for graph drawing, you might want to use the NodeExp library to generate the full trace, and then apply various transforms to the graphs to get the various steps (there's a singleStepEval function in there that performs a single step of the evaluation). You can then shove that output into pretty-hat (it has library calls) to generate dot files, stick that into dot, and display the pdf it renders for you. options. Look at hat-explore... perhaps a version of that that shows you the EDT, and allows you to click on nodes and mark them as correct or incorrect? I hope that lot's useful to you A final suggestion, at least the tools I've written recently, I've tried to keep pretty modular with thoughts of adding a GUI later, so you can probably use a lot of the NodeExp, HatAnim, Slice, PrettyHat, and HatDelta code. I've found that some of the older code is pretty modular, but some of it is fairly hard to navigate, so there may be more pickings in there to integrate. In short, I'm saying try not to reinvent the wheel too much, there's a lot of good code in there. Bob