I've been out of it for the last 10 days or so, so haven't had an opportunity
to respond to the draft. I have a LOT of comments on it, which shouldn't be
interpreted as a knock on the draft; I think it's excellent work, and just want
to see it (along with WG2) evolve to something that by consensus replaces
R[56]RS as the definitive standard.
Rather than spew a huge email with everything, I thought I'd break my responses
up into a number of topic emails. The first one is about exceptions (§§4.2.7
and 6.5).
PROBLEM: It's impossible to write a portable error handler that writes out the
message and obj's that were passed to ERROR.
This comes about because ERROR creates an `implementation-defined object'. I
would assume that this hides the whole exception class hierarchy a WG2
implementation might provide. Since the message and obj arguments to error are
presumably living in this implementation-defined object, it should be simple
enough to provide accessors to extract them, so that the above `portable error
handler' can be written.
Suggestion: Add
(ERROR-OBJECT? obj): returns #t if the argument is something created by
ERROR, #f otherwise. Any constraints on type disjointness are up to the
implementation.
(ERROR-OBJECT-MESSAGE obj)
(ERROR-OBJECT-IRRITANTS obj): have the expected meanings.
PROBLEM: Raising arbitrary objects as exceptions has been found to be nasty in
some other languages (Python and C++ in particular).
This one is a tad speculative, but I'm reluctant to encourage people to write
things like (raise 4), because of course it doesn't respect any module
boundaries. I think the intent with the descriptions of RAISE and
RAISE-CONTINUABLE was to allow exception hierarchies to be added in WG2 without
constraining them here. I would suggest adding a new procedure,
(MAKE-ERROR-OBJECT message obj...), which creates the implementation-defined
object ERROR is supposed to create, and adding a sentence to the RAISE and
RAISE-CONTINUABLE entries that says `The effect of applying this procedure to
an object not created via MAKE-ERROR-OBJECT is implementation-defined'. This
allows WG2 to do what it wants regarding exception objects, and to limit the
types of exception objects allowed, without breaking anything in WG1. ERROR can
be defined as
(define (error message . objs)
(apply make-error-object message objs))
EDITORIAL POINT: §6.5 should have a cross-reference to §4.2.7.
More to come -- v
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
