> > From: Thiago Arrais [mailto:thiago.arrais@...]
> >
> > My initial idea would be to allow the user to set breakpoints to
> > program expressions via the Haskell editor and have a graph reducing
> > machine show the graph reducing steps to the user in a step-by-step
> > approach. Aditional features include random expression evaluation
> > (like watches). I would mirror the Java debugger to let veteran
> > eclipse users feel more confident.
> >
> > I don't know which machine to use yet, but a Java implementation of a
> > graph reducer wouldn't be at all impossible, provided we have a
> > parser, a type checker and a lambda-lifter that would give us only the
> > 'code juice'. Sure it would not have many optimizations, but they
> > aren't really necessary in a debugger. My main concern here is how to
> > keep certain program information if the preceding components weren't
> > implemented by us.
>=20
> It sounds like you plan to implement a significant proportion of a Haskel=
l
> compiler. Do you already have a parser, type checker, and lambda-lifter?
> (why is a lambda-lifter necessary?)
What we need is some way to get around that implementation. Parsers,
type-checkers and lambda-lifters are already implemented elsewhere but
we need them to 'decorate' the program tree so that we know, for
example, wich program line corresponds to the graph that shown by the
debugger. Ideas are very welcome.
> A summary of Haskell debugging, as I know it:
>=20
> - HsDebug: http://www.cambridge.intel-research.net/~rennals/hw2003.pdf :
> GDB-style. Hooks in to GHC; removes most optimisations (e.g. tail-call) a=
nd
> performs optimistic evaluation. Not released (AFAICT) and depends on
> optimistic evaluation (an unreleased GHC extension).
>=20
> - HAT : http://www.haskell.org/hat/ : writes graph-reduction data out to
> log file, for post-mortem analysis.
Post-mortem analysis isn't exactly what we want. But maybe HAT is
worth a look or two, for catching the logging mechanism. We could get
the ideas for a state-driven, user-controlled mechanism.
=20
> - buddha : http://www.cs.mu.oz.au/~bjpop/buddha/ : re-writes source code,
> allows examination of graph while executing
I think this is the most similar approach to what I have in mind in
your list. My main concern to my approach is: will it be useful? I
mean, is graph reducing stepping sufficient to map haskeell program
execution (I am, for the time being, worried about Monads) and will it
give the end user the functionality he needs? I wonder what of those
'debuggers' is the most widely used on the haskeell community.
> - Hood : http://www.haskell.org/hood/ : "printf"-style; prints intermedia=
te
> values (to log file?)
>=20
> HsDebug is the least invasive, and most similar to imperative debuggers.
> Buddha and HAT both require recompilation but no modification to source.
> Hood requires changes to source.
>=20
> It sounds like you want to do something similar to buddha.
>=20
> Alistair.
|