[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Fahlman @ CMU-CS-C
- Subject: Another Ballot
- From: Kent M. Pitman <KMP @ MIT-MC>
- Date: Fri, 03 Jun 1983 20:32:00 -0000
- Cc: Common-Lisp @ SU-AI
A1 Yes PARSE-INTEGER is OK.
A2 No I prefer that declarations be special forms. I would prefer to offer
PROCLAIM with no argument evaluation and *PROCLAIM as a subr form
such that (PROCLAIM form1 form2 ...) is the same as
(EVAL-WHEN (EVAL COMPILE LOAD) (*PROCLAIM 'form1 'form2 ...))
That is, the subr form should not be "implicitly" in any EVAL-WHEN.
I would like to keep the common, purely declarative, case simple.
A3 B I strongly prefer B. I believe it to be maximally consistent with
the rest of the Common-Lisp design. I also believe that current
Lisp Users' models best support this view.
I would also accept a hybrid B/C with syntax as per B, but with
case-insensitive lookup. I slightly prefer B to this, however.
I believe C is just barely acceptable, but I think this will do
very bad things to users' models. Many users take a long time to
understand what |...| and / are about already; I believe trying to
separate contexts where they can be used will add undue conceptual
overhead for novices.
I strongly oppose A as inconsistent with the case-retention rules for
the "other half" of symbols. I think novices would be confused silly
A4 Yes Consistency between VECTOR-PUSH,etc. and PUSH sounds good.
A5 Yes I like NTH-VALUE. NTH was zero based and people can live with that.
I find such an argument spurious.
A6 --- I have no strong feelings on this named structure primitives issue.
A7 Yes I strongly support this. Users read too much into the symmetry of
names SET and SETQ. In a lexical lisp, this is far more dangerous
than a dynamic lisp. ALAN should just type (SETQ #.+ ...) to the
A8 Yes I think (APPLY '(LAMBDA ...) ...) should be left undefined and
implementors might be free to support it as an implementation-
dependent upward compatible extension. This will save implementors
from having to take any immediate action, but leave Common Lisp
more flexibility later on. Users should be discouraged from doing
A9 No If SVREF exists, then VREF maybe should exist for symmetry; otherwise,
it seems like SVREF should be SAREF instead ... Alternatively, SVREF
could be renamed VREF. I'm not sure any more what the full proposal
for arrays/vectors looks like any more. I'd rather defer this issue
until I can evaluate it more coherently.
A10 Yes Extra arg to MAKE-RANDOM-STATE sounds harmless and potentially useful.
A11 Yes Just this week I found the APPLYHOOK feature in the LispM and was
able to clean up some very ugly code which was trying to replace it.
The phrase "EVAL binds both *EVALHOOK* and *APPLYHOOK* to NIL
around calls to either of them." has a very nebulous "them" referent.
A12 No I like and use Destructuring LET a lot, but am sympathetic to peoples'
arguments that it is a data abstraction violation in general. I do,
however, agree with Weinreb's comments on DLET and suggest that he
propose this DESTRUCTURING-BIND primitive as an alternative.
A13 Yes Flush FIND-EXTERNAL-SYMBOL in favor of FIND-SYMBOL with extra value.
The extra value would be needed in any case to disambiguate the case
of FIND-SYMBOL of "NIL" ...
A14 Yes MULTIPLE-VALUE => MULTIPLE-VALUE-SETQ
A15 Yes Add ARRAY-RANK-LIMIT, etc. Even if these were the same values
everywhere, having people compare to symbolic names would be good.
A16 No This has certain SET/SETQ confusions about it that make me very
uncomfortable. The issue of "scoped" macros doesn't now occur but
might some day and I worry that if arg1 to SET-MACRO is ever anything
besides 'something, it may be hard to statically resolve in a useful
way. The minimal change that would make me happy is to call it
SETQ-MACRO or MACRO-SETQ or some such, but all in all, I'd rather
just flush this proposal.
MACRO has other problems (like it's a pain for programs like ATSIGN
and EMACS which may not realize it defines something). Why not just
change its name to DEFINE-PRIMITIVE-MACRO. I think that would
adequately discourage its use by novices while not introducing the
SET/SETQ problem I mentioned about above.
A17 --- This sounds superficially like a good idea, but I have done no
significant programming in such areas so can't adequately evaluate
the efficiency implications or the effect on the compiler of not
being able to predict an exact datatype returned from one of these
functions (potentially important on general purpose hardware). So
I'll abstain and hope you others know what you're doing.