[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
- Subject: Another ballot
- From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
- Date: Fri, 03 Jun 1983 13:44:00 -0000
- In-reply-to: The message of 3 Jun 83 02:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
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
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.
A3. Indicate which of the following you could live with, and which you
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
Yes. What ever happened to my observation about SUBSTITUTE-IF's argument
A5. Add KMP's (NTH-VALUE n form) for picking up one value from a form
that returns multiple values.
[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.)
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 ...) ...).
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.
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.
A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
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
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:
: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.
A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
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).
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.