[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Fahlman @ CMU-CS-C
- Subject: ballot A
- From: Glenn S. Burke <GSB @ MIT-ML>
- Date: Sat, 04 Jun 1983 02:15:00 -0000
- Cc: common-lisp @ SU-AI
A1. Add parse-integer.
A3. [Package names]
I could live with b or c. I have no strong objection to either.
A4. vector-push arg order.
Yes, fix it.
A5. Add KMP's (NTH-VALUE n form)
No objection if it is zero origined.
A6. defstruct primitives
I don't really care. The proposal was to supply an alternative
to named arrays, which i do not approve of in the white pages
as a mechanism for defining typed objects.
A7. eliminate SET and FSET
I am fairly neutral on this.
A8. (apply '(lambda ...) ...)
It should either be invoked in a null lexical environment, or be
totally illegal. In NIL, I have experimented with it both being
invoked in a null environment, and being invoked in the "current"
environment. The latter makes (mapcar '(lambda ...) ...) work
as a Maclisp user might expect, but is totally ridiculous otherwise.
Also, I do not see how it can be tractable to interpret it as if it
were #'(lambda ...), because by the time you see it you have lost
A9. Propose that we reinstate VREF.
Shucks, i had just written documentation stating that this was
obsolete. I don't really care. I would prefer to have primitives
to access the simple array types.
A10. Add an optional integer seed to MAKE-RANDOM-STATE.
A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
A12. Add a simple form of destructuring LET macro.
Not as proposed.
I would like a destructuring primitive which provides exactly
the functionality defmacro provides, including &mumbles. It
should not be LET based; my experience with destructuring LET
is that (besides grossness with LET*) the extra parentheses
needed by LET syntax make it unreadable. The NIL compiler defines
(defmacro debind-args (pattern call-form &body body) ...).
This is also used by the interpreter.
A13. A modification to INTERN and FIND-SYMBOL
This sounds reasonable.
A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
Can we shorten these to MV-SETQ and MV-BIND? Instead of
(multiple-value-setq (a b c) ...) it will be tempting to abbreviate to
(setf (values a b c) ...), although i guess that is not supported.
A15: Implementation limits
Yes we should have constants with the values of those limits,
but No, we SHOULD specify certain minimums within which portable
code may blithely run correctly.
A16. Guy proposes that we get rid of MACRO
Yes, but (setf (macro-function ...) ...).
A17. Reduction to canonical form
For rationals, yes, definitely.
For the complex case i am not so sure. I guess i will defer to
others on this, but i feel uncomfortable with it.