Questions from M. Hagiya

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

T. Yuasa and M. Hagiya of Kyoto University independently implemented
Common Lisp for the Data General MV/10000.  They had a number of
questions about the definition of Common Lisp, which they accumulated in
a file.  Hagiya presented me a hardcopy of this file when I visited them
in Kyoto last month.  I answered some of the questions, but there were
others whose answer I either didn't know, or considered undefined.  I
told Hagiya that I would pass these questions through to the other
Common Lisp designers, and that if there were an answer I would try to
get it back to him.  I have paraphrased most of the questions, both to
correct the English and to clarity the intent (I discussed each question
with Hagiya).  (His English isn't bad at all; he even got the "BOA
constructor" joke!)

First, the questions that I think might reflect problems or ambiguities
with the Common Lisp definition:

If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)),
does Common Lisp specify that this "works", i.e. that the symbol "moshi"
(a Japanese word for "if") can now be used as the name-symbol of a
special form, just as well as "if"?  (I told him I thought the answer
was "no", but it's not stated clearly in the manual.)

In a defmacro argument list, (&whole w a b) presumably means that there
must be exactly two arguments to the macro, which a and b will be bound
to, and furthermore that w will be bound to the whole thing.  By
extension, (&whole w a) means that there must be exactly one argument,
and so (&whole w) means that there must not be any arguments at all.  If
so, then the (&whole w) case is evidently useless, and if what you
really want is to just have a macro that lets you examine the body
yourself and doesn't play with argument lists, you need to do (&whole w
&rest ignore) or something.  Is this really the definition of Common
Lisp?

Is this an example of legal syntax:  #c(0 #.pi)

What do equal and equalp do for structures?  (The same question came up
on this mailing list recently.  Hagiya asked "Are they obvious?", and
since he and I agreed what the obvious definition must be, I told him
yes.  However, as we discussed, the manual doesn't tell.)

Suppose we redeclare a structure (evaluate defstruct for a structure
we've already defined), and a slot that had originally been declared
non-read-only is redeclared to be read-only.  Should the access function
for that slot be deleted (fmakunbound'ed)?

Should the streams that are arguments to make-broadcast-stream,
make-concatenated-stream, or make-echo-stream be of the same element
type?

What is the element type of "bit sink" (that is, make-broadcast-stream
of no arguments)?  (I told him that T seemed right to me, but agreed
that the point needs clarification.)  Also, what is the element type of
a concatenated stream made of no streams?  (I'm not sure it matters.)

If the reader sees a close-paren at top-level, must this signal an
error, may it be ignored, or what?

If only line-by-line I/O is supported, may the function "print" do a
terpri after printing a form rather than before?  (I am not completely
sure what he means here, but I think the point was that the DG operating
system is only allowing him to do line-at-a-time I/O, and the definition
of "print" was not completely implementable in this framework.)

While LOADing a file, what is the value of *standard-input*?  (I told
him that I thought for a character file it really ought to be the file
stream, but the manual needs to say and doesn't.  What should it be when
the file is binary?)

Now, in addition to these questions, he also had some particular
comments, and some questions that I had no trouble answering but might
indicate points at which the manual needs to be more explicit.  The rest
of this message consists of these comments and points; I consider these
less important than the above, so if you're tired you can stop reading
at this point.

He feels that the algorithm to determine whether a type is a sub-type of
another is vague, and feels it should be spelled out more.

He says that it is specified that any structure is a sub-type of
"structure", but "structure" is not in Table 4-1.  The latter is true
but I can't find where the former is stated.

In 17.4, the parameters are referred to as "bit-array", although the
data type specifier used in chapter 4 is "bit-vector".  There is no
error here as far as I can see, but apparantly Hagiya found it
inconsistent.

Can a symbol be a function and a macro at the same time?  (Of course I
told him no.  His internal representation is actually sort of set up
to allow this, but of course the interpreter has to do exactly one thing
with a form, so actually his implementation doesn't do anything unusual.)

Recovery from a name conflict in packages seems to be
implementation-dependent.  Can it be a fatal error?  (Yes.)

Can the value of the parameter "package" for package functions be a
symbol or a string?  (Yes, the manual is quite explicit about this.)
How about *package*?  (It has to be a package object, as returned by
find-package.  The manual is not particularly unclear, but might
emphasize this point.)

How do you implement "rationalize"?  (I didn't know off hand.  By the
way, this makes me suspect that these folks don't have a copy of the CMU
sources.)

He had some confusion about parsing after #\.  I do think the manual
could be more explicit about the algorithm for deciding where the break
after seeing #\.

If the character set is ASCII, how do we represent ASCII control
characters?  (Implementation dependent.  Their implementation currently
uses #\^A, and I told him that I thought other implementations probably
did exactly that as well.)

He was confused by the term "alphadigit" in Table 22-3, apparently not
having read the fine print at the bottom.  I presume that the function
alpha-char-p needs to reference *read-base* in order to function properly?

What is the initial value of *default-pathname-defaults*?  (Implementation
dependent; the manual should say so explicitly.)

They were also both quite confused about how to implement #,.  I belive
that the problems they were having are based on the issues that were
discussed on this list recently.  #, definitely needs better
explanation.