[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU
- Subject: Typechecking
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Sat, 6 Feb 88 21:52:32 PST
- Cc: labrea!Common-lisp-object-system%SAIL@labrea.Stanford.EDU
- In-reply-to: David A. Moon's message of Fri, 5 Feb 88 14:40 EST <19880205194056.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: Is there anyone who actually wants "should signal an error" and won't
accept "results are undefined"? If not, let's change it. If so, that
person should be agitating to change Common Lisp as well.
It's on my list of "Clarifications" which need to be written up into
cleanup proposals. The intent DEMANDED by many users is that there
be one mode of compilation/execution that insures memory integrity and
type surety. CLtL's universal excuses "it is an error" and "the results
are undefined", isn't good enough to satisfy that; but Dick's attempt
at phraseology "should signal an error" is close to what's needed.
Certainly CLOS and Common Lisp need to follow the same conventions.
There are numerous other places where the CLOS development has laid
cleanup issues at the Common Lisp door [type-disjointness of some basic
data types, "function specs" for setf generic methods, etc].
-- JonL --
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>