On 04/30/11 02:21, Vincent Manis wrote:
> 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.

Thanks!

> PROBLEM: It's impossible to write a portable error handler that
> writes out the message and obj's that were passed to ERROR.

Yes, I think that would be good to fix. However, I'm not too upset that
it's not defined in WG1, as it looks like the sort of thing that will
emerge as a de-facto standard after some trial and error, and then be
standardised in R8RS or similar.

> 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.

This is a perfectly reasonable API, though, IMHO!

> PROBLEM: Raising arbitrary objects as exceptions has been found to be
> nasty in some other languages (Python and C++ in particular).

Yeah, as I see it the issue here is to allow integration with proper
exception hierarchies. We avoided trying to standardise one in WG1, as
it would always be incompatible with existing implementations; no matter
how we try and write the APIs, implementations disagree on the subtype
relationship between different kinds of exceptional situation.

> 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.

Quite right on all counts. But, we allow (raise 4), while certainly not
encouraging it. Nonetheless, an error system based around numbers is not
entirely without precedent (if woefully unhygienic and unfriendly);
errno comes to mind ;-)

> 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.

Hrm, but not all exception systems would map neatly to having a message
and some irritants.

Personally, I'd prefer if there was an abstract notion of exception
defined, that at least has a human-readable representation:

(EXCEPTION? foo)
(EXCEPTION->STRING foo)
...and for advanced implementations, (EXCEPTION-BACKTRACE foo) etc...

Then error can be defined as a subtype:

(ERROR? foo) ;; implies (EXCEPTION? foo)
(ERROR-MESSAGE foo)
(ERROR-IRRITANTS foo)

...and EXCEPTION->STRING on an ERROR object is defined as producing
something like "<message> (<irritants>)".

RAISE et al might then be constrained to work with EXCEPTION values
only, and this can be mapped into complex type hierarchies as required.

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports