[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-Lisp@SU-AI
- Subject: Ballot A
- From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
- Date: Fri, 03 Jun 1983 21:27:00 -0000
A1. PARSE-INTEGER Yes
A2. PROCLAIM is a function Yes
A3. Package name lookup none of the above
I agree that making the syntax of the package-name part of a qualified
name exactly like the syntax of the symbol-name part is an improvement,
and I'm willing to give in and allow vertical bars here. Note that this
syntactic equivalence applies both to READ and to PRINT.
Note that package names are given in three essentially different contexts:
As prefixes in qualified names of symbols
As arguments to functions that take a package object or name, e.g. USE-PACKAGE
As the name when creating a package, e.g. MAKE-PACKAGE first argument.
I am unhappy about any scheme that involves a string-based user interface
to something that uses case-sensitive lookup. I have two proposals, the
first being preferred:
1) Package-name lookup is case-insensitive; you cannot have two
distinct packages whose names differ only in case. The case of
the name given to MAKE-PACKAGE is remembered, thus if it is not
all upper-case the package name will contain escape characters
when printed in a qualified name.
1a) An acceptable variant says that MAKE-PACKAGE calls STRING-UPCASE
if given a string (but not if given a symbol) as the name.
2) Package-name lookup is case-sensitive but the user interface is in
terms of symbols rather than strings; thus MAKE-PACKAGE, USE-PACKAGE,
EXPORT, etc. demand symbols as their package-name arguments. These
symbols are compared with SAMEPNAMEP, not EQ, thus it doesn't matter
what package they are in. The serious problem with this is: does
PACKAGE-NAME return a symbol or a string, and if it returns a symbol,
what package is the symbol in, or is it uninterned?
A4. VECTOR-PUSH arg order Yes
A5. NTH-VALUE Mildly in favor
A6. Named-structure primitives Neutral
I don't care whether the named-structure primitives are considered to
be part of the language or part of defstruct, i.e. whether they appear
in the White Pages or in the Implementor's Guide to Installing Defstruct.
I am opposed to the :NAMED argument to MAKE-ARRAY and MAKE-VECTOR appearing
in the white pages, although in fact it will exist in both Symbolics and Spice
Common Lisp dialects.
A7. Flush SET, SETF None of the above
I favor the way Steele had it in the manual last time I looked, which
was that SET is retained due to the grandfather clause, and its frequent
usefulness, whereas FSET is removed due to confusion with SETF and lack
of frequent usefulness.
A8. (apply '(lambda ...)) is an error No
I am opposed to this because it would be a break with the past whose
implications are not well-understood. Later we can decide it is bad
style and discourage it, if we like.
I think there are good reasons to allow a function name to stand for
a function object, when the function object contains no free lexical
references. If there are free lexical references, it is an error.
The NIL interpreter seems to do a nice job of warning about this error.
It is already noted in the manual that APPLY with a symbol as the first
argument looks up the functional value of that symbol in the global
environment, not the caller's environment. (Of course, (APPLY 'FOO...)
is exactly analogous to (EVAL 'FOO).) Even the latest version of
the manual forgets to say this for FUNCALL, but surely FUNCALL and APPLY
are supposed to be consistent.
A9. Add VREF Neutral
A10. Integer seed for MAKE-RANDOM-STATE Yes
Stress that this gives you a -repeatable- sequence of random numbers,
and that the implementation makes "an effort" not to give the same
sequence for different seeds.
A11. Add APPLYHOOK Yes
A12. Add DLET No
I think we should have destructuring, but not with this name and
not with the syntax of LET. By voting against this it is incumbent
on me to propose an alternative; I'll try to send out a proposal
early next week. There are more issues than recognized by the
simple proposition that DLET be added.
I think it is probably a good idea to defer destructuring until the
second edition of the manual because there is probably going to be a
substantial amount of discussion. For now, let's have it only in
DEFMACRO where the issues are very clear.
A13. Two values from INTERN, FIND-SYMBOL Yes
A14. MULTIPLE-VALUE-SETQ Neutral
If it is called ...-SETQ, it must accept any even number of
subforms, not just 2.
A15. Implementation limit constants Yes
I agree with DLW and BSG about putting a floor under these.
The constants are still valuable, e.g. for checking whether a program
will work in an implementation without exhaustively testing all paths
through the program. If you want suggestions for the floors, I'll
suggest 3 dimensions, 50 arguments, and 10 values. The actual hard
limits in my implementations are 7, 63, and 10 (easily raised to 63)
in the LM-2, and something higher in the 3600 (7, 255, and 255 except
that there are probably other limits that come into play a little below
Is the limit on number of arguments different for functions with
&REST or &KEY than for fixed-maximum functions? Does the limit on
number of arguments apply to the length of the last argument to APPLY?
A16. Flush MACRO Yes, but
I agree with EAK that it should be SETF of MACRO-FUNCTION.
My objection to MACROP being a ps****predicate (i.e. returning
the expander function), was that people should not be allowed to
call that function directly; only EVAL and MACROEXPAND-1 may call it.
This was for macro memoization and in the hope that checking of the
length of the form could be centralized rather than done separately
by each expander function. These aren't strong enough reasons to
turn down the proposal, especially since we have *MACROEXPAND-HOOK*
now. Checking of the length of the form is really subsumed into
checking of the syntax of the form, and needs to be done separately
by each expander function, I now believe.
A17. Gaussian rationals No vote
It is already the case that (integerp 4/2) is true. There was a slight
braino about this somewhere in the Laser manual.
Having Gaussian rationals behave as an extension of the real rationals
seems superficially plausible, but I don't consider myself competent to
evaluate the implications. Let me ask the $64 question: will the result
of any function, other than type-checking functions and transcendental
functions, be affected by this change (i.e. are there other functions
that treat complex numbers on the real line different from real numbers)?