Another ballot

[Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>]

    Date: Fri, 3 Jun 1983  02:27 EDT
    From: Scott E. Fahlman <Fahlman@CMU-CS-C>

    A1. Proposed that we add BSG's PARSE-INTEGER function in place of the
    defunct PARSE-NUMBER.
Yes.  I'd like to modify the spec to say that it does not parse a Common
Lisp <integer>, but a sequence of digits to produce a Common Lisp <integer>.
The person writing the calling program and its documentation choose the
input base, not the user.  
    A2. Propose that PROCLAIM, the replacement for top-level DECLARE, will
    evaluate its arguments as a normal function.  Note that PROCLAIM must be
    wrapped in an implicit (EVAL-WHEN (COMPILE LOAD EVAL)...) in order to
    work, so whatever the args are, they must be evaluable at compile time.
Yes.  
    A3. Indicate which of the following you could live with, and which you
    prefer:
b. or c.
    A4. Moon has pointed out that VECTOR-PUSH and VECTOR-PUSH-EXTEND take
    their arguments in an order that is inconsistent with PUSH.  Propose to
    fix this.
Yes.  What ever happened to my observation about SUBSTITUTE-IF's argument
order inconsistency?  
    A5. Add KMP's (NTH-VALUE n form) for picking up one value from a form
    that returns multiple values.
In favor.
    [I am mildly opposed to this.  As Moon points out, this would have to be
    0-based and would be non-intuitive for that reason.  
  Would 1-based be MORE intuitive if you know Common Lisp?
							 In addition, it is
    rare to want some single value other than the first.]
  I disagree with this.  This is precisely for that case where you do, and
  there is really no other way to handle it.
    ---------------------------------------------------------------------------
    A6. Propose to add GSB's proposal for a set of primitives to create
    named structures.  (This was in recent mail -- I don;t want to repeat
    the whole thing here.)
Mildly opposed.  
    A7. EAK has asked that we vote on this:  Propose to eliminate SET and
    FSET from Common Lisp in favor of (SETF (SYMBOL-VALUE ...) ...) and
    (SETF (SYMBOL-FUNCTION ...) ...).
Can't say.  I'm not wise enough to make a tradeoff between consistency and
convenience on a case-by-case basis.  I am reminded of the guy in "Life of
Brian" who says, "*I'M* not different!": the consistent primitive-less 
setters are certainly consistent with each other, and with the rest they
are inconsistent.  If we really believe that SET and FSET are must-have's,
I would wish the restoration of PUTPROP on identical grounds.
    A8. EAK has also asked that we vote on this: Propose that in Common Lisp
    it is an error to do (apply '(lambda ...) ...).
Not sure.
    A9. Propose that we reinstate VREF.  This is a fairly useless synonym
    for AREF with one index, but people keep expecting to find it there,
    even some who have not been through all the oscillation on this.
Opposed.
    A10. Add an optional integer seed to MAKE-RANDOM-STATE.  A given seed in
    a given implementation always creates a random state object that
    generates the same sequence of "random" numbers, but different seeds
    create random states that are <mumble, handwave> unrelated.  As it now
    stands, the only way to create distinct but repeatable random states is
    to start from copies of the same state and run RANDOM for (very) different
    numbers of cycles.
In favor.
    A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
In favor.
    A12. Add a simple form of destructuring LET macro.  DLET would allow
    arbitrary list or tree structures in place of the LET variables.  The
    leaves would be symbols, the variables to bind.  The LET values would be
    picked apart according to these patterns and the pieces assigned to the
    variables.
I propose we hold off until we understand what we intend to do with 
destructuring, or make such a thing as proposed a yellow-pages extension.
    A13. A modification to INTERN and FIND-SYMBOL, suggested by Moon:
    Both of these functions return two values.  The first is the symbol that
    was found or created.  (FIND-SYMBOL does not create a new symbol, but
    returns NIL for the first value if no existing symbol was found.)  The
    second argument is NIL if no existing symbol was found and takes on one
    of three values if a symbol was found:
      :INTERNAL
      :EXTERNAL
      :INHERITED (implies internal).
    We can now flush FIND-EXTERNAL-SYMBOL.  If you want this, call
    FIND-SYMBOL and see if the second value is :EXTERNAL.
In favor.
    A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
Indeed!
    A15: Steele propose the following:

    There has been a lot of flak about the decision that every
    implementation must support arrays of rank up to 63.  There are similar
    problems with numbers of arguments, and Moon has raised an objection
    concerning the equating of valid array dimensions with fixnums.

    I propose that we recant a bit, and set no hard limits, but realize that
    programs may not be portable by reason of pushing on those limits.  So
    that programs may probe the environment, introduce these constants:
This, to me, is not as transparently clear as it may seem.  It is very hard
to parameterize your program for variable limits on array rank.  This is 
not the same as "maximum array size" or "maximum string size", against
whose effects you can easily parameterize your program.  While I am in favor
of the new variables, which say what the implementation's limits are, I
think that it is strongly in the interests of portability to impose SOME
lower limit on maximum array rank, even if it is 3 or 4 or 10.
    A16. Guy proposes that we get rid of MACRO, which is a trap for
    unsuspecting users who ought to be enjoying the benfits of DEFMACRO.
    We need something for DEFMACRO to expand into.  Guy proposes a function
    named SET-MACRO that takes two evaluated arguments: the symbol that is
    to be defined as a macro and the expansion function.  So if we want to
    define a macro named FOO and its expansion function is
    (LAMBDA (CALLFORM) ...), we (or rather defmacro) would use
    (SET-MACRO 'FOO #'(lambda (callform) ...))

    In effect, SET-MACRO does whatr one might express as
	    (SETF (SYMBOL-FUNCTION 'FOO)
		  (make-a-macro-object #'(LAMBDA (CALLFORM) ...)))
    except that SET-MACRO hides the existence of this odd macro-object
    (if indeed that is the way it is implemented internally).
In favor.
    A17. Per EAK's suggestion, require (integerp 4/2) to be true and also
    require (integerp (complex 4 0)) to be true.  That is, rationals always
    reduce to canonical form, and so do Gaussian rationals.
Strongly in favor.