I have recently been getting into using the debugger, and I must say I'm
impressed. It is very nice that you get the full power of the interactive
compiler in very much the right value-binding context to understand how
things are inside your functions.
I do have a few comments and queries though. In case any of this is platform
specific, I have mainly been using it on x86 Linux with a 2.4.21 kernel.
1) The example in the documentation doesn't quite work as stated. The problem
seems to be a general one: the only break-points seem to be at the head of a
function (i.e., with the parameter bindings done, but not any bindings in
let-expressions). When you go up the stack, values bound between the head of
the function and the point of execution are not in scope. I.e., if you have
something like:
fun f x = let y = h x; in g y end;
and break in g, when you go up to f, you can't see y (you can rerun the
binding, but that may not be the right thing to do if h has side-effects).
2) If you mistype a function name in the parameter to breakIn, it doesn't
cause an error (maybe this is a side-effect of a feature? it does seem to be
very tolerant of the function names, e.g., you seem to be able leave off
structure names and can stop in functions that aren't visible outside their
structure).
3) It would be very nice indeed if you could break at points where an
exception is raised. I can see that this might be a bit tricky because an
awful lot of my ML code is failure-driven, so lots of exceptions get raised
"unexceptionally" and you'd want a way of describing "exceptional"
exceptions, In my case the ones I'm interested in are the ones that aren't
going to be caught.
4) Is there are any run-time overhead in having code compiled with
PolyML.Compiler.debug true?
5) ProofPower puts a wrapper around the compiler's read-eval-print loop (by
calling PolyML.compiler with appropriate arguments to do the reading and
printing). It would be nice if we could do the same with the debugger's
read-eval-print loop.
Regards,
Rob.
