[plt-scheme] 300.2

MzScheme and MrEd are now version 300.2 in the SVN repository trunk.

The main change is an experiment in MzScheme's reporting of exceptions.
Internally, MzScheme sets a continuation mark each time it calls a
procedure. The default error display handler extracts a "stack trace"
based on those marks:

 Welcome to MzScheme version 300.2, Copyright (c) 2004-2005 PLT Scheme Inc.
 > (define (f x) (car x))
 > (f 10)
 car: expects argument of type <pair>; given 10
   at f
   at loop
   at read-eval-print-loop

The idea is that this information can be added without significantly
affecting run-time performance (unlike other forms of debugging that
I've tried). This change doesn't affect development in DrScheme, since
DrScheme provides its own debugging support.

As you can see, the built-in trace is less precise and less complete
than the information that errortrace or DrScheme generates, and it
includes internal functions that errortrace/DrScheme would not see.
Internal functions appear because the mark is set by the core
interpreter. Less information is available because only the procedure
name is used (no source location), and because the marks are set only
for procedure calls to Scheme-defined functions (not for each
expression). The information is also less well defined than
errortrace's information; for example, MzScheme sometimes converts
`((lambda (x) E1) E2)' to `(let ([x E2]) E1)', in which case `(lambda
(x) E1)' won't appear in the stack trace.

Marking only at procedure calls makes the built-in stack-trace cheap
enough. I've constructed microbenchmarks where the cost is as much as
10%, but it's in the noise for all realistic programs that I've tried.
Let me know if you see anything different.

Source-location information might be improved without increasing the
run-time cost. Already, when MzScheme can't find any reasonable name
for a procedure, it gives it a name based on the source location. Maybe
the source location should be preserved more often for stack traces. Or
maybe, when you need that much information, it's still best to use
errortrace. I'll wait for feedback on this point.


Use `raise-user-error' to report an error that doesn't print with a
stack trace. For example, when an unrecognized command-line flag is
presented, the "cmdline.ss" library uses `raise-user-error' to report
the error. The `raise-user-error' procedure creates an instance of the
new `exn:fail:user' struct, and the default error display handler
doesn't show a stack trace for this type of struct.

Matthew