Cleanup issues from Japanese technical working group

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I have comments on excerpts from this.  For most of the issues
raised, I have no comment.  Feel free to forward these comments
back to our Japanese friends if desired.

    1) CLtL says nothing about whether structure or array is self evaluating
       form. [5.1.1]
       It is suggested that not only numbers, characters, and bit-vectors,
       but also structures, arrays, vectors, packages be self-evaluating forms.
       Yuasa:  There may possibly be some reason that these objects are not
	       allowed to be evaluated.  But the reason is not known.
       This simplification is convenient both for the user and for the implementor.
       Note that some implementations such as Exper Common Lisp signal an error
       when those objects that CLtL does not explicitly say are self-evaluating
       are being evaluated.

      <<The Rationale for this could easily be provided in the standard.
	Does this need an Issue? >>

It's not true that CLtL says nothing about this; the bottom of page 54
in the English edition says evaluating any other object is an error.
I don't know what the rationale was; unless somebody knows, we can't easily
provide it in the standard!

At Symbolics we pondered this for a while and settled on the idea that
only objects of type (OR CONS SYMBOL) do anything special when evaluated,
and all other objects evaluate to themselves.  We haven't had any problems
as a result of this.

CLtL says something about implementation-dependent extensions for
evaluating other types of objects, but we decided that this didn't make
sense for any of the object types defined by CLtL.  An implementation
could certainly invent a new, non-COMMON object type with a new way of
evaluating it, and then that (OR CONS SYMBOL) would be extended to (OR
CONS SYMBOL other-type) in that implementation.  But since a portable
program presumably wouldn't use any objects of that
implementation-dependent type, this should't interfere with portability
even if we define that all objects of types defined by CLtL, other than
CONS and SYMBOL, are self-quoting.

Evidently current practice varies between implementations.  This needs an
issue if we want to change it, but since "is an error" allows complete
implementation-dependent freedom, we don't have to say anything if we
think the status quo is okay.

    1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3]
	<< I think this is a wording change rather than an Issue.>>

I don't think this is a problem at all, since 22.1.2 (page 343) is very
explicit about this.

    5) Same keyword parameter can appear more than once in an actual argument 
       list. [5.2.2]
       This is necessary to overwrite passed keyword arguments.
       << New issue KEYWORD-ARGUMENT-DUPLICATES? >>

Not an issue, 5.2.2 (page 62 in the English edition) is already very
explicit about this "If more than one such argument pair matches,
it is not an error; the leftmost argument pair is used."

    4) ---
    Q: Is there any way to escape from Lisp context.
    A: Some systems, such as Lisp machine have no concept of escaping.
    This is needed for Lisp systems under stock operating systems.
    It is necessary to determine the name even if the function
    may be implementation dependent.

    Recommendation: (QUIT) will be a proper word for this operation.

    << Seems like it goes in the environment section. >>

I remember this was discussed at length a couple years ago, and the
conclusion was that the semantics of quitting varied so much between
implementations that there was no point in trying to standardize
anything.  Even without thinking about multiprocess systems, nor about
Lisp machines, you have to ask whether after quitting the Lisp vanishes
or can be restarted, whether a command string can be returned to the
operating system, whether a success/failure code is required to be
returned to the operating system, etc.  Finally it is unclear how a
portable program could usefully benefit from this.