[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Guy.Steele at CMU-10A
- Subject: Mini-ballot
- From: Kent M. Pitman <KMP at MIT-MC>
- Date: Tue, 09 Nov 1982 00:54:00 -0000
- Cc: common-lisp at SU-AI
(1) My experience with LispM function specs leads me to believe that
something along these lines is worthwhile. I waver between saying "yes"
to (c) because I am not firm on the details and it might be better to
wait and (a) because I know it's a valuable tool and I've seen what
happens when you don't have it. With regard to (b), I object rather
strongly on the following counts:
* I would prefer that they be statically analyzable. I can figure out
at code analysis time (eg, compile time or at the time I'm reading
someone else's code) what (DEFUN (GET 'FOO 'BAR) ...) means. And have
a pretty good idea of what the code is trying to say. But if the
person does (DEFUN (GET FOO BAR) ...), I can analyze this code only
formally and have no good feeling for what it's going to do.
I think definitional forms should try to stay simple and the programmer
should write (SETF (GET FOO BAR) #'(LAMBDA ...)) in the few cases
where he needs it.
I would be uncomfortable with special-casing (ie, requiring) QUOTE
in this kind of form, so restricting things to the (GET 'FOO 'BAR)
case will not make me feel better.
* If (DEFUN (GET 'FOO 'BAR) (X) X) means (SETF (GET 'FOO 'BAR)
#'(LAMBDA (X) X))
then (DEFUN F (X) X) should mean (SETF F #'(LAMBDA (X) X)) and
not (SETF #'F #'(LAMBDA (X) ...)). This incompatibility bothers me.
I'd like to see a concrete proposal for exactly what LispM style stuff
we'd put in before I vote for (a) over (c), however.
A more conservative alternative is to go the Maclisp route and say that
the useful case of DEFUN'ing properties can be done by
(DEFUN (sym prop) bvl . body)
and not go for either the function spec or the SETF approach for now
until more thinking has been done. This syntax would be fairly easily
upgraded later if people were encouraged to never use a sym which was
on the keyword package in such a DEFUN so that later upgrading if desired
could be done in an upward compatible fashion.
This is preferable in my mind to HEDRICK's (DEFUN-PROP ...) proposal
because it is not as verbose and it is upward compatible in a way that
doesn't introduce arbitrarily many new operators.
(2) I guess I buy the argument that constants oughtn't have *'s around them.
Knowing by looking at a thing whether it's intended to be bound is
certainly a useful property.