Re: issue COMPILE-ENVIRONMENT-CONSISTENCY

[Dan L. Pierson <pierson%mist@multimax.ARPA>]

    Um, unspecified is unspecified: the implementation can do whatever it
    wants.  Soemthing in the C stabdard (pragmas, I think) was defined in
    this way, and for a while gcc would run rogue, or gnu emacs, or, ...
    -- depending on what it could find -- whenever it encountered a
    pragma.
    
    So this particular problem is not a reason to prefer "unspecified" to
    "is an error" -- both allow "crash and burn".
    
Obviously, we need a term which allows a reasonable number of
implementation options without allowing GCC-like obnoxious behavior.
This is part of what the whole committee has to consider when we
decide what our new set of error terms should be.  My claim is simply
that we badly need to break "is an error" down into some more
controlled and useful cases everywhere in the standard.

PS: In fact the CLOS spec defines "unspecified" as harmless at worst.
    There is another term, "undefined", that allows crash and burn.
    (88-002R, pp. 1-6,1-7)