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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports