[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another ballot
A1. Yes, do PARSE-INTEGER. But no pound-signs or other hair, please.
A2. I think I am opposed to the details of the new PROCLAIM. I agree
with most of what is proposed, but I do not like the idea of an
implicit EVAL-WHEN, at least if I understand what is meant. I
would like PROCLAIM to be evaluated in exactly the same way as
DEFUN. That is, if you type it at the top level of Lisp, or it
is at the top level of a file, it would work in the expected
way. As I understand it, you are proposing that a PROCLAIM
could occur in a random place in the middle of code, and it
would still happen at COMPILE or LOAD time. I think this is a
bad idea. The whole idea of restricting DECLARE to the
beginning of blocks was to minimize this kind of thing.
A3. We can live with anything that you can implement, but would prefer
B, to treat the package part just like the symbol part. MUCH
easier for users to remember.
A4. Yes, fix VECTOR-PUSH and VECTOR-PUSH-EXTEND.
A5. No, we don't need more MV mechanisms. As always, I propose to
simply MV's further by removing them.
A6. No, I am satisfied with an almost-transportable DEFSTRUCT.
A7. No, do not remove SET. While we are at it, CONS seems like an
unnecessary relic. It is after all a special case of a
A8. No, do not make it an error to do (APPLY '(LAMBDA ... That is,
don't do just that. However I agree completely that the whole
issue of what is a function object needs further thought. If
a complete analysis of this results in (LAMBDA not being a
function object and thus not allowing APPLY on it, I am willing
to accept that. I suspect that it is too late to do such an
analysis for this release of Common Lisp.
A9. Abstain on VREF.
A10. Yes, allow a seed in MAKE-RANDOM-STATE.
A11. My concern with APPLYHOOK is whether we are ready to standardize
that hook. If all of the implementors and potential
implementors agree that these are the right hooks, then
by all means. I defer to the Spice people on this, since we
are using their evaluator.
A12. Yes, allow simple destructuring. Do not destructure the family cat.
A13. No, do not make INTERN return multiple values. I am willing to
allow it for FIND-SYMBOL, however.
A14: Yes, that name seems reasonable. Would you consider using
MV-SETQ, etc.? While I am just as happy to discourage the use
of all MV primitives, do we really want primitives with names
that are that long?
A15: In general I accept the proposal on bounds. I think some
implementations might be able to live with arrays with a small
maximum rank. However I do not believe that this is true for
arguments for functions. I agree that it is a pain to
implement large numbers of arguments for functions. I know.
It has caused us real hassles. Nevertheless I believe it is
necessary. I am willing to let implementors cop out on
array ranks if they want to, but not on arguments. I believe
that the only limits on number of arguments should be those
imposed by the size of memory, stack space, etc. It is bad
enough to have arbitrary limits in Pascal. In a language
like Lisp it is unforgiveable. We probably need to set an
actual number as the minimum maximum number of arguments. The
number must be set large enough to make it impossible for
an implementation to get away with any of the easy solutions,
and small enough that we can still implement CLISP on a micro.
By the way, would you allow us to set CALL-VALUES-LIMIT to 1?
A16. OK, do what you want with MACRO.
A17. Yes, reduce all numbers to their simplest form (but not floating
point to integers...)