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.