[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Error Terminology
- To: RPG@sail.stanford.edu
- Subject: Error Terminology
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Tue, 22 Mar 88 13:21:26 PST
- Cc: common-lisp-object-system@sail.stanford.edu
- In-reply-to: Dick Gabriel's message of 22 Mar 88 0811 PST <8803221617.AA07359@edsel.lucid.com>
re: \item{\bull} No valid program may depend on the effects of this
situation, and all valid programs are required to treat the effects
of this situation as unpredictable.
Granting the complaint about "must not extend" being an un-enforceable
clause, then I think this substitute for it is also un-enforceable (i.e.
how can you determine whether a program treats some result as unpredictable).
But the example you have found is brilliant; it cleary shows that the
design cannot be silent about the situations you call D'4. That seems to
be precisely the bug in CLtL -- that silence in this situation implicitly
means "is an error", which for other reasons was defined to cover the
"extensible" case too.
Actually, I didn't think the original wording was all that bad -- "an
implementation must not extend ...". Maybe what was bad about it was
that it wasn't identified as a "designer's note" or "implementation
note".
-- JonL --