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 [email protected] And is made up of http://www.ccil.org/~cowan Contradiction. --William Blake _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
