Mini-ballot

[Kent M. Pitman <KMP at MIT-MC>]

(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.