Kent M Pitman <pitman@world.std.com> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| > Not quite -- it says:
| > Exceptional Situations: None.
| > To me, that suggests "never throws an exception".
|
| Not to me. :)
|
| I think you will will get in a LOT of trouble if you read it that way...
| (I certainly never intended it to be read that way when I wrote it.)
+---------------
See my other response (to Christophe Rhodes). You're right; I'm wrong.
+---------------
| First, exceptions are not thrown. Exception is not even terminology
| in the language standard.
+---------------
Oops! Sorry for dragging in a "trigger" word with bad connotations.
I didn't mean "throw" as in Lisp's "throw/catch", I meant a much more
colloquial, general meaning, as in to "toss your cookies" or "barf
an error". So no argument: "signal a condition" is reallt what I meant.
Again, apologies for the confusion.
+---------------
| Third, beyond the issues of terminology and interrupts and other things
| reserved to implementations, there is the fact that the Exceptional
| Situations is just a place to put stuff that didn't make sense in the
| description.
+---------------
Yeah, I began to gather that from a re-reading of CLHS 1.4.4.10
"The ``Exceptional Situations'' Section of a Dictionary Entry".
+---------------
| I definitely did NOT redundantly list things in there that are in the
| Description, and I definitely DID often make arbitrary decisions about
| where something when when there was a choice. e.g., the FOO function might
| say "Checks that its argument is a frob; otherwise, signals an error."
| in the Description and nothing in the Exceptional Situations, or it might
| say nothing about the argument other than that it's a frob in the argument
| signature, and the Exceptional Situations might say "Signals type-error if
| the-frob is not a frob."
+---------------
Or maybe nothing at all in the Description *or* the Exceptional Situations
sections, since [as I noted in my other reply, referenced above] the
global statement in CLHS 1.4.4.3 "The ``Arguments and Values'' Section
of a Dictionary Entry" says [which I had overlooked]:
Except as explicitly specified otherwise, the consequences
are undefined if these type restrictions are violated.
So if a type is given in Arguments and Values (and for SUBTYPEP
one *is* -- the args must be "type specifiers") then it is not
*necessary* (however useful the reminder might be in some cases)
to say anything at all in the Description or the Exceptional Situations
sections, unless the behavior is *different* from the default.
And since "undefined" can mean *anything* (perhaps signalling a condition,
but also perhaps doing nothing at all, hanging, or self-destructing),
saying "signals type-error if the-frob is not a frob" in Description
or Exceptional Situations that is actually a *tighter* specification
of the behavior than the default (which is one of the reasons one
might want to say it, when applicable).
+---------------
| I don't think this at all. It seems to me that (valid-subtype-spec-p 'foo)
| could signal an error.
+---------------
Having re-read those sections of the CLHS more carefully, I now
completely agree. Mea culpa. I really put my foot into it with
this one. Apologies to all.
-Rob
-----
Rob Warnock, PP-ASEL-IA <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607