[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gall: Bug Report]
Here are some Common Lisp questions sent to me by Nick Gall of Gold
Hill. I'll take a crack at answering some of them when I get the time,
if nobody else beats me to this.
-- Scott
***************************************************************************
Date: Tue, 19 Mar 1985 17:39:00 -0000
From: Nick Gall <Gall at MIT-MULTICS.ARPA>
To: Fahlman
Re: Bug Report
Posted-Date: 19 Mar 85 13:41 EST
Acknowledge-To: Nick Gall <Gall@MIT-MULTICS.ARPA>
These comments are presented in the style suggested by Postscript
to the Ada (TM) Language Reference Manual. The format of the
header is as follows:
!section SECTION#(PARAGRAPH#) NAME ISO-DATE
!version REFERENCE-MANUAL-VERSION-NAME
!topic SUMMARY-OF-COMMENT
The Ada RM states that,
The topic line should contain a one line summary of the
comment. This line is essential, and you are kindly asked to
avoid topics such as "Typo" or "Editorial comment" which will
not convey any information when printed in a table of
contents. As an example consider:
!topic Subcomponents of constants are constants
Note also that nothing prevents the topic line from including
all the information of a comment, as in the following topic
line:
!topic Insert: "... are {implicitly} defined by a
subtype declarartion"
-----------------------------------------------------------------
!section None Nick Gall 85-03-19
!version Digital Press 1984
!topic Paragraphs should be numbered
Paragraphs should be numbered as in the Ada (TM) Language
Reference Manual. This would make identification of particular
paragraphs in discussions much simpler.
-----------------------------------------------------------------
!section 14.1(2) Nick Gall 85-03-19
!version Digital Press 1984
!topic Copying arrays
Although functions such as SUBSEQ state that the copy made of an
array is of the same type, they say nothing of the two other array
attributes, fill pointer and adjustable.
The question is, "Should copied arrays share these attributes
with their originals, or should they be simple?"
The answer should be stated in the standard.
I think the best solution is to make simple copies by default,
and allow an optional or keyword arg. to specify that all
attributes should be copied.
-----------------------------------------------------------------
!section 18.3(2) Nick Gall 85-03-19
!version Digital Press 1984
!topic Implied copying in the trim functions
Although it is implied that the result of the string `trim'
functions is a copy of the original strings, it is not explicitly
stated. Since all the other functions which can potentially make
copies of strings/arrays state this explicitly (e.g. SUBSEQ,
CONCATENATE, SUBSTITUTE), the trim functions should also.
-----------------------------------------------------------------
!section 18.3(2) Nick Gall 85-03-19
!version Digital Press 1984
!topic Implied copying in the STRING-{UP | DOWN}CASE functions
Although it is implied that the result of the {up | down}
functions is a copy of the original strings, it is not explicitly
stated. Since all the other functions which can potentially make
copies of strings/arrays state this explicitly (e.g. SUBSEQ,
CONCATENATE, SUBSTITUTE), the {up | down} functions should also.
-----------------------------------------------------------------
!section 9.1(6) Nick Gall 85-03-19
!version Digital Press 1984
!topic Pervasiveness of declarations over FLET and LABELS
Example:
(defun the-many-function-names-foo (x)
(declare (inline foo))
(foo x) ; First call of FOO
(flet ((foo (y z) (zap z y)))
(foo x x)) ; Second call of FOO
(foo x)) ; Third call of FOO
According to the paragraph in question: "Declarations that do not
concern themselves with variable bindings are pervasive,
affecting ALL CODE IN THE BODY OF THE SPECIAL FORM." Thus, the
second call to FOO will be open-coded; in spite of the fact that
the second call of FOO refers to a function which is totally
unrelated (except by name) to the FOO referred to in the other
two calls.
To prevent this, one has to provide a declaration
within the FLET form:
...
(flet ((foo (y z) (zap z y)))
(declare (notinline foo))
...)
...
But what if this FLET were the expansion of a macro? How is the
macro expansion function supposed to know which pervasive
declarations will affect the functional objects specified in the
FLET?
In an analogous case concerning special variables instead of
function names, no such redeclaration is necessary:
(defun the-many-variables-foo (foo)
(declare (special foo))
(fram foo) ; dynamic binding
(let ((foo (boop)))
(frab foo)) ; local lexical binding
(zoop foo)) ; dynamic binding
Declarations concerning function names should be treated as
special variable declarartions are: references are pervasively
affected, but not bindings.
The last paragraph in each of the function name declarations
(e.g. FUNCTION, INLINE, etc.) which begins, "Note that the rules
of lexical scoping...", suggests that function names and special
variables ARE treated analogously. If this is so, it should be
made explicitly clear in section 9.1.
-----------------------------------------------------------------
!section 9.1(12) Nick Gall 85-03-19
!version Digital Press 1984
!topic Non-Top-Level use of PROCLAIM
Can PROCLAIM be used, other than at top-level? Since DEFVAR,
etc., are proclamations and can be used at other than top-level,
the answer to this question seems to be `yes'.
Is PROCLAIM a `declaration', i.e., must it appear only where a
declaration is allowed? Since it is allowed at top-level (unlike
DECLARE), and it is a function, and since the other proclaiming
forms (e.g. DEFVAR, etc.) could not be considered declarations
(since they perform evaluation and assignment), the answer must
be no.
Then what is the effect of using PROCLAIM (or one one the other
proclaiming forms) in the middle of a function? For example:
(defun foo (a) (zap a) (proclaim '(special a)) (zark a))
Does the first reference to A refer to the local binding? Does
the second reference refer to the global?
Some mention of the effects of the non-top-level use of PROCLAIM
and the other proclaiming forms should be made.
-----------------------------------------------------------------
!section 7.5(14) Nick Gall 85-03-19
!version Digital Press 1984
!topic Scope and Extent of local function names
NOTE: See 9.2 (ftype, function, inline).
Example:
(DEFUN CREATE-MAKEP (MAKE)
(FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE)))
#'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER)))))
(SETQ FOO (CREATE-MAKEP 'HONDA))
(FUNCALL FOO 'BILL) => ?????
Question: What does CAR refer to when it is used in the closure
returned by CREATE-MAKEP? I.E., What is the scope and
extent of the binding of a local function name to a
functional object?
Section 7.1(1) states that "There are two spaces of variables in
Common Lisp, in effect: ordinary variables and function names."
And the function name binding control structures appear in the
section entitled "Establishing New Variable Bindings".
I suggest that Common Lisp go all the way, and allow a
SPECIAL-FUNCTION-NAME declaration that would be analogous to the
SPECIAL declaration for "ordinary" variables.
Such a concept would make the idea of
ordinary-variable/function-name binding and assignment much more
consistent.
-----------------------------------------------------------------
!section 5.2.2(4) Nick Gall 85-03-19
!version Digital Press 1984
!topic Lambda variables with the same `name'
Ex. 1:
(lambda (a a) (values a))
Ex. 2:
;; Assume (not (eq p1::a p2::a))
(lambda (p1::a p2::a) (values p1::a p2::a))
Ex. 3:
;; Assume (eq p1::a p2::a)
(lambda (p1::a p2::a) (values p1::a p2::a))
1. Is Ex. 1 legal? If so, which args., value is returned?
My answer: No, and the CLRM should state this.
2. Is Ex. 2 legal?
My answer: Yes.
3. Is Ex. 3 legal?
My answer: No. it is just like Ex. 1.
The point that Exs. 2 + 3 point out is that it is the symbols
THEMSELVES that name variables, not their (qualified)
print-names. This distinction should be pointed out.
This same comment applies to all the other environment
establishing functions (section 7.5).
-----------------------------------------------------------------
!section 5.3.2(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Redeclaring Constants with DEFCONSTANT
It should be mentioned in this paragraph, as it is in 5.1.2(6),
that,
Constant symbols defined by DEFCONSTANT also become reserved
and may not be further assigned to or bound (although they may be
redefined, if necessary, by using DEFCONSTANT again).
-----------------------------------------------------------------
!section 7.8.5(3) Nick Gall 85-03-19
!version Digital Press 1984
!topic Are identical TAGs legal?
If so, which one is gone to? If not, it should be stated.
-----------------------------------------------------------------
!section 7.8.5(3) Nick Gall 85-03-19
!version Digital Press 1984
!topic Items which are not symbols, integers, or lists in
a TAGBODY
The sentence,
An item in the body may be a symbol or an integer, in which
case it is called a TAG, or ... a list, in which case it is
called a STATEMENT.
Does this mean that any other atom is illegal? If so, it should
be stated.
-----------------------------------------------------------------
!section 9.1(10) Nick Gall 85-03-19
!version Digital Press 1984
!topic Replace: "... the parameter {of} NONSENSE named Z."
-----------------------------------------------------------------
!section 23.1.2(11) Nick Gall 85-03-19
!version Digital Press 1984
!topic Replace: "... if no syntactically correct {namestring}
was seen."
-----------------------------------------------------------------
!
-----------------------------------------------------------------
!section 10.3(9) Nick Gall 85-03-19
!version Digital Press 1984
!topic Which bindings are copied by COPY-SYMBOL?
"the initial value and function-definition of the new symbol
will be the same as those of SYM..."
Does this mean that the (dynamic) value of the variable
referred to by SYM, at the point where COPY-SYMBOL symbol is
invoked, is copied? Or, does it mean that the `initial', i.e.
global value of the special variable named by SYM is copied?
Although the wording seems to suggest the latter, it should be
made clearer.
The same questions and suggestion applies to the
function-definition copied by COPY-SYMBOL.
-----------------------------------------------------------------
!section 15.2(39) Nick Gall 85-03-19
!version Digital Press 1984
!topic The effect of NCONC on '() arguments
"The arguments are changed, rather than copied."
Surely, this does not apply to the arguments which are empty
lists. Also, the last argument is NOT changed, right?
Are dotted-lists allowed? If so, the result of a call such as,
(NCONC '(1 2 . 3) NIL)
should be made explicit.
-----------------------------------------------------------------
!section 15.2(55) Nick Gall 85-03-19
!version Digital Press 1984
!topic What may N be in BUTLAST?
MUST N be a non-negative integer? Or can it be negative (with a
neg. N having the same effect as a zero N)? The constraints on
the type and range of N should be made explicit.
-----------------------------------------------------------------
!section 15.2(57) Nick Gall 85-03-19
!version Digital Press 1984
!topic When is LIST modified in NBUTLAST?
Shouldn't the condition, "If the LIST has fewer than N
elements..." read, "If the LIST has N or fewer elements...".
-----------------------------------------------------------------
!section 15.5(8) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is (TAILP NIL list) true or false for every list?
"This preicate is true if SUBLIST is a sublist of LIST (i.e. one
of the conses that makes up LIST)." According to this criterion,
NIL is not a sublist to any list since it is not a cons.
"...TAILP is true if (NTHCDR n list) is sublist, for some value
of N." According to this definition NIL is a sublist of every
list, since the (NTHCDR (LENGTH list) list) is NIL for every
LIST.
Although a phrase in the definition of LDIFF, "If SUBLIST is not
a tail of LIST (and in particular if SUBLIST is NIL)," seems to
indicate that NIL is NOT a sublist (or tail) of any list, this
should be stated explicitly in the definition of TAILP.
-----------------------------------------------------------------
!section 20.1(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is *APPLYHOOK* funcalled for special forms?
"The variable *APPLYHOOK* ... is used when a function is about to
be applied to arguments." Does `function' refer to a functional
object which is in fact a function (i.e., its args. are evaled
before it is called), or does it refer to any functional object
(e.g., `special' functional objects)?
Later in the paragraph, it is stated that,
The apply hook function is used only for application of
ordinary functions within eval. It is not used for
applications via apply, or funcall, for applications by such
functions as map or reduce, or for invocation of
macro-expansion functions...
This paragraph does not really address the "application of
ordinary functions within eval" but rather the "ordinary
application of functions by eval." Also it does not clarify the
action taken for special forms.
This paragraph should be made clearer.
-----------------------------------------------------------------
!section 21.3(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic What does CLOSE Return?
I think it should return the STREAM it was given to close. This
would make it symmetric with OPEN: OPEN returns an open stream,
CLOSE returns a closed stream.
-----------------------------------------------------------------
!section 20.1(last-1) Nick Gall 85-03-19
!version Digital Press 1984
!topic Is nil declared by defconstant?
...all constant symbols declared by DEFCONSTANT, such as NIL,
T, and PI.
If NIL is declared by DEFCONSTANT then it can legally be
redefined according to section 5.1.2(last):
Constant symbols defined by DEFCONSTANT ... may be redefined,
if necessary, by using DEFCONSTANT again[].
Is such an interpretation correct?
-----------------------------------------------------------------
!section 4.8(1) Nick Gall 85-03-19
!version Digital Press 1984
!topic The meaning of the word `convert'
Does coerce `convert' (i.e., change the type bits) and return the
original object (or the pointer if typed pointers are supported)
when possible (e.g., coercing a string to an array of
(unsigned-byte 8) in some implementations); or does coerce ALWAYS
create and return a new `equivalent' object; or does the Common
Lisp spec. not define this?
-----------------------------------------------------------------
!section 5.3.2(7) Nick Gall 85-03-19
!version Digital Press 1984
!topic Lexical variable with the same name as a named constant
A named constant is declared using DEFCONSTANT. DEFCONSTANT
PROCLAIMs that a symbol always names a special variable (which
happens to have a fixed value). This proclamation applies to ALL
bindings and references. Therefore, after such a proclamation,
no lexical variable with such a name can be used.
If this is the case, when would the compiler ever have the
opportunity to
...issue warnings about bindings of the lexical variable of
the same name [as a name declared by DEFCONSTANT to be
constant].