Instance variables

["Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>]

Sorry for the late replies; I just got around to reading all of my
Common Lisp mail.  This is mostly about the meta-issue of what we should
be discussing.

I also strongly agree that we should be trying to discover a set of
primitive hooks that every implementation can provide, so that several
message-passing systems can be provided in a yellow pages library.  For
us to try to design a single message passing system and try to impose it
on all the users would be a mistake.  Therefore, there's no need for us
to send mail saying which way message passing should work; rather we
should try to assemble a list of requirements that will drive the
definition of the primitive hooks.

Those of us who are familiar with existing systems such as flavors or
loops can contribute by making sure that the primitive hooks will be
sufficient to produce a reasonably efficient implementation of that
system.  We'll have to work together on this, since probably nobody is
familiar with the requirements of all systems.

If we can agree on this strategy, then we can keep this discussion more
focussed and useful.  For example, the issue of "but isn't defstruct
sort of similar" should be postponed, since it is very unlikely to
affect the design of the primitive hooks.

As Scott Fahlman says, we will have to discuss some of the higher-level
issues (how should variables work, how should inheritance work), but we
need not get agreement on all of them.  If we all agree about some
issue, then we can feel free to make the primitive hooks support the
agreed answer; if it seems clear that we do not agree about some issue,
then rather than argue it to death, we can just try to design the
primitive hooks to support various different answers.

I'd like to reply to one thing that Scott said:

    Date: Thursday, 1 November 1984, 10:01-EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    1. There is great demand for the best possible substrate for a flavor
    system.  Many of the Lisp Machine people understandably oppose a
    mechanism that would slow down flavors even a little bit in the interest
    of generality, or that would not support some of the more complex
    features of flavors.

Well, actually, if there's some big conflict here, it need not cause a
breakdown in cooperation.  Just because there is a set of primitives
that each implementation must implement, and there is a yellow-pages
implementation of flavors, does not mean that we are required to use
that implementation; we could provide the hooks, but keep using our
existing implementation that doesn't use those hooks.  Of course, it
would be better to avoid such a situation, but if worse comes to worst,
we could do it.

I'd also like to reply regarding one specific technical point, namely,
the "lexical" behavior of instance variables:

    Date: Wednesday, 31 October 1984, 15:58-EST
    From: Steven <Handerson@CMU-CS-C.ARPA>
				      but it is my strong opinion and belief that
    instance variables are naturally lexical (accessible only inside methods).

In the implementation of Flavors that will be included in our next
software release (Rel 6.0), this is exactly how it works.  A lambda
expression that is closed inside a method can refer to the instance
variables of the instance, as a natural extension of the meaning of
lexical scoping.

    Date: Wednesday, 31 October 1984, 17:17-EST
    From: Kahn.pa@XEROX.ARPA
    I like the notion of thinking of a DEFMETHOD as something that expands
    to a giant LET binding the instance variables to their values.  The
    problem then is with SETQ and the like.
    Flavors sort of takes the view that an object is a functional closure
    and that DEFMETHOD "edits" the definition of the function.

I don't understand this; what's the problem with SETQ?  An internal
function of a method can SETQ the instance variables just fine, even if
it's returned (i.e. even if it is an "upward funarg").