Questions, comments and clarifications on clarifications

[Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>]

    Date: Sat, 14 Dec 85 18:30:16 pst
    From: edsel!eb@su-navajo.arpa (Eric Benson)

    82.  Is it gratuitous pseudo-generality to allow an arbitrary number of
    arguments to XOR, instead of requiring exactly two?  Give an example.

One could argue that XOR should take an arbitary number of arguments for
symmetry with AND and OR, even if we can't come up with a satisfying
example.  Symmetry is important to keep the language self-consistent and
easier to learn.

As long as I'm sending mail, here are a few more quick comments:

249: There continues to be widespread disagreement among the expert
users I know about circular list arguments to mapping functions.
Several feel that it's natural, elegant, and seriously useful.  I do not
have any strong personal opinion, and I do not tend to use this style
personally, but I don't think this issue is nearly as clear-cut as many
of the others in "clarifications.text".

268: I suspect that COPY needs to be defined more specifically than it
is in "clarifications.text" before we can decide whether it ought to be
in the language.  While I like the basic idea very much, I'm worried
about a number of details.  Someone already brought up the question of
whether copying an array means preserving all of its attributes, such as
displacement.  If you COPY an interned symbol, is the result interned or
uninterned, and what's the symbol-package?  Are the conses of the
property list copied also, or are the property lists shared?  What if
you copy a keyword symbol?  Can you copy a package, and if so what is
the name of the copy?  If you copy a pathname, is the result allowed to
be EQ to the argument?  Can you copy a stream object that's open to a
file and positioned 254 characters into the file?  Can you copy an
output stream that's in the middle of writing characters to a file that
it's creating itself?  If you copy a closure, do you get a new closure
that shares the variable environment with the original, or does the
environment get copied too?  What other such issues might there be?  I'd
rather not express an opinion on COPY until a more detailed
specification is proposed.

425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the
proposal doesn't say what it means.  I'd like to hear what this argument
is supposed to be defined to mean, expressed in a way that is
implementation-independent in any sense, such that this argument could
ever be used in a portable program and relied upon to do any specific
thing in particular.

439: What is COMPILEDP defined to do if you give it a lexical closure
over a function that is compiled?

439: [The following is not well thought out; I apologize in advance.]
All this stuff about the COMPILE function retaining the interpreted
definition is starting to make me nervous about the line between a
programming language and a programming environment.  This, and also the
"how do you undefine an X" issue, point out that the current design is
wavering between trying to be a language specification and trying to be
a programming environment specification.  Obviously, in Lisp it's hard
to draw the line.  However, we are all assuming that there is some kind
of distinction.  To pick an extreme but illustrative example, suppose
there were a purported Common Lisp implementation in which the CAR
function, before returning the car of a cons, printed out some message
on the terminal.  Most of us would consider this a violation of the
Common Lisp spec; that is, if I tried to port my program and my program
failed to work because of this message, I'd blame the CL implementation,
not my program.  But LOAD is defined in CLtL just as much as CAR is, and
I haven't heard anybody complain that a Lisp is out of conformance with
the standard because LOAD prints out a message.  I don't have any
specific constructive suggestions at this time, but I think if we don't
figure this stuff out, we may be letting ourselves in for trouble and
surprising portability problems.

443: Do you also want to say that APROPOS might find some specific
symbols more than once, assuming that 187 is accepted?