Vincent Manis scripsit:

> It is somewhat less useful than I had at first thought, I realized
> earlier today that most built-in functions would create a subtype of
> ERROR-OBJECT, and that ERROR in particular would do so. I'd therefore
> like to suggest loosening the language a bit, though I don't have
> immediate new wording to suggest.

Not necessarily; the objects returned by R6RS ERROR belong to sibling
types of the various implementation-signaled errors.  Note that R7RS WG1
does not have a notion of subtypes at all.

> > I'm really opposed to that: simple programs ought to be able to
> > throw simple objects, especially when the conditions don't represent
> > exceptions.
>
> Since every WG1 program is (supposed to be) a WG2 program, that means
> that it's perfectly acceptable for a WG2 module to offer a procedure
> that does a RAISE 4, and and for another WG2 module that also, for
> very different reasons to do the same. This would make using these two
> modules together extremely difficult, which sort of defeats the idea
> of programming-in-the-large.

Yes, but that's a matter of self-discipline in module writing.  If
you make the effect of (raise 4) implementation-dependent, there is
no guarantee that it will be caught by the exception subsystem at
all.  Perhaps you meant that some object is raised, but which object is
implementation-dependent?

--
I suggest you solicit aid of my followers       John Cowan
or learn the difficult art of mud-breathing.    cowan@ccil.org
        --Great-Souled Sam                      http://www.ccil.org/~cowan

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