Ballot A

[David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>]

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
    Flush FIND-EXTERNAL-SYMBOL
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
    255).
    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)?