fill-pointer maybe

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Richard,

It looks to me like you and some others are missing a key concept.

There are an awful lot of places in CLtL where it is specified that
certain things have to work, but where the manual is silent on what
happens if those conditions don't hold.  A classic example is a built-in
function whose arguments "must" be of a certain type.  As a rule, these
unspecified situations should be considered to "be an error".

That phrase means that a legal Common Lisp implementation is free to
extend the language to handle this situation in some allegedly useful
way; it is not required to signal an error or to self-destruct.
Portable Common Lisp code may not depend on any such extensions, but an
implementation is free to extend all it wants.

In some cases where CLtL is silent, it is an oversight and a case can be
made for changing to a "signals an error" case or for specifying exactly
what must happen in that situation.  In most cases, however, the
language is left open-ended deliberately.  The feeling of the designers
was that Common Lisp is a living, growing language, and we didn't want
to bind it all up too tightly by trying to specify EVERYTHING.  "Signals
an error" was only specified in those cases where we felt that an error
signal was essential and where detecting the error would not impose too
great a performance penalty on some calsses of machine.

Now, if an implementation takes advantage of its freedom to extend the
language, and if it does not provide a compiler mode or some other tool
that flags the use of such non-portable extensions, then that
implementation is unsuitable for developing portable applications.  (I
could name some names, but I won't.)  Nevertheless, such implementations
are perfectly legal and are operating within the spirit of the Common
Lisp spec.  The language was meant to be extensible; that was an
important part of the original charter that we set for ourselves.

So, for the purposes of validation, you should treat these unspecified
cases as "is an error" cases and leave them alone (unless it is unclear
whether the case is or is not specified).  It couldn't hurt to make a
list of the ones you encounter for later discussion, but in almost all
cases the default answer is "this situation is an error; implementations
may do what they like".  It is the job of the validation suite to make
sure that the cases that ARE specified are handled correctly.

-- Scott