[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Memorial Day Ballot: comments on other people's entries
- To: common-lisp@su-ai
- Subject: Memorial Day Ballot: comments on other people's entries
- From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
- Date: Wed, 01 Jun 1983 01:40:00 -0000
- In-reply-to: The message of 31 May 83 15:35-EDT from BENSON at SPA-NIMBUS, The message of 31 May 83 15:01-EDT from Dave Dyer <DDYER at USC-ISIB>, The message of 31 May 83 05:35-EDT from JONL.PA at PARC-MAXC.ARPA
Date: Tuesday, 31 May 1983, 12:35-PDT
From: BENSON at SPA-NIMBUS
6. No. NIL already has too much attached to it. A decent compiler will
detect variables which are set but not used. It's not important
enough to add another "keyword" usage to NIL.
The issue here is the difference between (MULTIPLE-VALUE (NIL X) (FOO))
and (LET (TEM) (MULTIPLE-VALUE (TEM X) (FOO))). In other words it's not
an attempt to get increased efficiency, but an attempt to increase clarity
by avoiding the need to introduce unnecessary "fake" variables. It's not
a big deal but I thought an explanation might be helpful.
14. No. I don't think the user needs to be concerned with whether a
call to READ is at top level or not, since READ has to use a
special variable to keep track of its state.
The issue is how do you know when to re-bind this special variable? What
if a reader macro, while reading from a file, asks for some input from the
terminal for some reason? What if the same reader macro does the same thing
while reading from the terminal? What if the reason it asked for input wasn't
that it was programmed to, but that it got an error? READ can't tell whether
it was called with the intent of being a recursive call or the intent of being
a top-level call, although there are ways it can guess that work a lot of
21. Put them in the GLOBAL (excuse me, LISP) package, instead of
KEYWORD. Otherwise, users will be typing #+:FOO.
Of course if the things in *FEATURES* are required to be keywords then
the #+ and #- macros will read in the keyword package or use string-equal or
otherwise arrange for you not to have to type a colon every time.
no need to specify. One ought to be able to push any symbol onto
*FEATURES*. The object after #+ and #- should be read just like any
other. Remember, it can be a list, too.
This is a reasonable position. In other words, MACSYMA:INTEGRATION and
CIVIL-RIGHTS:INTEGRATION could be two different features from two different
packages, that you might want to test for separately. Saying that features should
be keywords, i.e. that packages lead to too much complexity here, is a reasonable
position, also. The Lisp machine does the latter currently, but that doesn't
mean much. I'm still neutral. But I'm not sure everyone has seen the
point of both sides.
Date: 31 May 1983 1201-PDT
From: Dave Dyer <DDYER@USC-ISIB>
7. Flush CATCH-ALL, UNWIND-ALL NO! Otherwise there is no way to escape
the predefined error semantics. These
provide the essential gross hook that
allows implementation of whatever variant
is necessary. Example: The oly kind of
CATCH Interlisp HAS is effectively
Conditions are not throws. I think Fahlman sent a message in the past few days
that explained this pretty well. I'll be proposing a condition system for Common
Lisp in a few weeks (which could stretch into months, of course).
20. APROPOS, PPRINT return NIL Ok. Rather than a separate family to
specify type of results,
I'd prefer an optional argument to specify
what to do. I usually use
T-> return list
otherwise (APPLY* X --) and
return list of non-nil results
This seems like a good idea, at least for APROPOS. Better than
introducing a new function. Both APROPOS and PPRINT already take an
optional argument, so they may need to be converted to keywords. The
default should be to print out and return nothing.
Date: 31 MAY 83 02:35 PDT
Why "but ..."
5 - What about functions that don't pass their keylist on; e.g.
MAKE-ARRAY ? Is it really true that :allow-other-keys will
have the proposed meaning in *every* keyword-taking function?
Yes. What if someone passes his keylist on -to- MAKE-ARRAY?
The meaning of a lambda-list for DEFUN, for lambda forms, and
for DEFMACRO ought to be perceptually the same
I am in very strong disagreement with this. Functions and special forms
are fundamentally different. "Destructuring" in the lambda list of a
function refers to taking apart THE VALUE OF AN ARGUMENT AT RUN TIME.
"Destructuring" in the "lambda" list of a macro refers to taking apart
THE SYNTACTIC STRUCTURE OF THE INVOKING FORM AT COMPILE TIME. These are
as different as can be. Beginners have enough trouble understanding
this without our throwing additional roadblocks in their way.
Especially is this matter of uniformity important for auto-documentation.
Wouldn't it be nice if you could write
(DEFUN FOO ((A B) C) ...)
(DEFUN FOO (L C) (PROG ((A (CAR L)) (B (CADR L))) ...))
so that ?= type of helpers would show you more about the syntax
of input arguments?
What if I wanted to say that L was a list and C was an integer? What
if I wanted to say that the first argument was a date and the second
argument was a string which was the name of someone on the Common Lisp
What a loss if such facility worked for DEFUN definitions, but
not for DEFMACRO definitions (and vice-versa)!
Of course you can always get the auto-documentation to say anything
you like, by using (DECLARE (ARGLIST ...)), at least on the Lisp machine.