Re: Mini-ballot

[Daniel L. Weinreb <dlw at SCRC-TENEX at MIT-MC>]

    Date:  8 Nov 1982 1810-MST
    From: Eric Benson <BENSON at UTAH-20>
    (1) It should not be necessary to extend DEFUN in this manner.
    (SETF (GET 'FOO 'BAR) #'(LAMBDA ...))
    should do exactly what you want.  Is there a problem with this?
Several.  Among others, a "definition" special form is parsable; on the Lispm
it records the source file name and checks for invalid redefinitions, etc.
I won't bother to go one since this seems to have been decided in the
right direction.

    Date:  8 Nov 1982 1958-EST
    From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
							 Do you gurantee
    that we can always do (APPLY (GET 'FOO 'BAR) args)?
We do guarantee that if you get a function object by calling the appropriate
function (the Lispm calls it FDEFINITION) on the function spec, then you
can apply what you got, but that doesn't mean we have to make any statements
about what you got.

    Date:  9 Nov 1982 0152-EST
    From: HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)
				  However I would like to have someone define
    what the construct for MACRO's, FEXPR's (if Common Lisp has such
    things), and any other odd things that DEFUN can generate.  If it is not
    possible to do that, then I think we would be better off using (PUTPROP
    'FOO 'BAR '#(LAMBDA ...  
Pardon me, but this doesn't make any sense.  The function spec FOO refers
to the function "cell" of FOO, whether it holds a macro or a function or
whatever.  (defmacro (:property foo bar) xxx) would mean to put onto
foo's bar property the same object that (defmacro baz xxx) would have put
into foo's function "cell".  There aren't any alternative constructs for
macros.

			     Furthermore, I would like to request that the
    this definition include a specification of the actual data structure to
    be used for interpreted functions.  
Gee, I thought that defining the format of functions was exactly what you
didn't want to do.  However, FDEFINITION of a defined function-spec is
guaranteed to return a function, suitable for APPLY and FUNCALL; it
is NOT allowed to return (expr lambda ...) or anything like that.
So I think function specs are actually the way to solve the problems that
you are bringing up.

    Date:  9 November 1982 0433-EST (Tuesday)
    From: Guy.Steele at CMU-10A

    I might believe that (APPLY '(:PROPERTY FOO BAR) args) shouldn't work,

In the Lisp Machine, symbols are a special case:  it is defined that all
symbols are functions, and when applied, they apply their definition.
However, it is not defined that all function specs in general are
functions and do the analogous thing just the way symbols do.  Actually,
we could make this change if we wanted, simply by saying that it's
illegal to have a function spec that looks like (LAMBDA ...).  I'm not
convinced that this would be a good idea, though.

    However, if you believe in the thing-name distinction, then it is
    even more important that ((:PROPERTY FOO BAR) 3 5 :START 7) work
This is exactly what I argued, about a year or two ago.  It's the general
"normal evaluation"/"functional evaluation" distinction.  If #'(:property a b)
works then, by analogy, ((:property a b) ...) ought to work.  However:

    Date: Tuesday, 9 November 1982  07:44-EST
    From: Scott E. Fahlman <Fahlman at Cmu-20c>

    I am really getting scared.  Allowing ((:property foo bar) ...) seems to
    me to open up all sorts of evil and hairy possibilities.
This is what everybody else told me, including Moon.  My feeling on the
matter is that we did, frankly, leave a semantic asymmetry in the by
leaving it in its current state.  Zvona's argument that the users expect
((:property a b) ...) to work is an important one: this is an instance
of a fundamental principle of user-interface, which makes sense applied
to language design too.  I still feel that ((:property a b) ...) really
ought to work, but I have already accepted Fahlman's argument and am
slightly scared myself.  Note that I don't know what Moon thinks about
this; I haven't discused it with him in some time.

As for the asterisks issue, I abstain (I don't think I have anything
useful to contribute and you guys seem to have the issue under control).