Vincent Manis scripsit:

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

I filed a ticket for this.

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

The issue here is not so much users raising random objects as the
fact that implementation-defined conditions may be almost anything.
We wanted to make sure that it was easy to implement R7RS exception
handling on top of almost any kind of native condition system.

In particular, the requirement of R6RS that implementation-defined
conditions be defined in a particular way was identified by the WG as
one of the barriers to moving from R5RS to R6RS.  In R6RS a condition
can either be a record whose class is a subclass of &condition, or
else a sui generis object (a compound condition).  R6RS requires
certain condition classes to exist, all of which are record types.  The
fact that condition predicates and accessors have to transparently
handle both ordinary and compound conditions, and that the definers
for conditions do not have to be used (define-record-type suffices),
means there has to be a special hack in the record system's predicates
and accessors to allow them to handle compound conditions as well as
ordinary record instances.

WG2 will have a package for R6RS-style conditions, but exactly
what that will involve is as yet unclear: it may have just record
conditions, or compound conditions also.  I suspect it will not have the
implementation-defined conditions, though it might have predicates and
accessors for them to provide a standard interface.

> I would suggest adding a new procedure, (MAKE-ERROR-OBJECT message
> obj...), which creates the implementation-defined object ERROR is
> supposed to create,

I don't have a problem with this, though I think it's less useful than
the predicate and accessors, so I filed another ticket.

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

I'm really opposed to that: simple programs ought to be able to
throw simple objects, especially when the conditions don't represent
exceptions.

> EDITORIAL POINT: §6.5 should have a cross-reference to §4.2.7.

Fixed and pushed to the repo.

--
Do what you will,                       John Cowan
   this Life's a Fiction                cowan@ccil.org
And is made up of                       http://www.ccil.org/~cowan
   Contradiction.  --William Blake

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