Re: accessor functions

[Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>]

    Date: Thu 24 Jul 86 16:45:33-PDT
    From: Dan Carnese <Carnese@SRI-KL>

	Date: Thu, 24 Jul 86 14:50 EDT
	From: David A. Moon

	I and most (but not all!) of my users agree with this philosophy
	and use it also.

I agree with one amendment: I'd use the same conc-name for all the
classes (flavors) of a protocol.  Not all flavors that implement a given
protocol need have some common ancestor, at least in theory, although
usually they do and so usually what Gregor said (class-tree) amounts to
the same thing.  (See further discussion of this issue, below.)

	    Date: 23 Jul 86 13:27 PDT
	    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

	    While generic functions let you use a conc-name of nil I personally
	    don't like this style.  As an example, using conc-name nil would allow
	    the accessor for all things which have a name to be just "NAME".  I
	    prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
	    of class.

Right, and the point here is that CLASS is a protocol.

    Well, the obvious problem with this convention is that you have to change a
    potentially large number of function names if you ever decide to rename a
    class.  

No, only if you decide to rename a protocol.  Renaming an individual
class, an individual implementation of the protocol, doesn't incur that
cost.

    Seriously, though, there is a good argument that the semantics of type
    operations should be tied to each other, not to a particular symbol naming
    the type.  E.g., the push and pop functions should be defined in terms of a
    (push pop) complex, not a random name like "stack".  Of course, there's no
    problem with using the variable "stack" to refer to this complex, in just
    the same way that the variable "zero" can be used to refer to the object 0.

My point is to make the distinction between names of implementations and
names of protocols.  The generic concept of pushing, as part of a
protocol that includes pushing, popping, and other things that make
sense for something that implements the abstraction of
being-like-a-push-down-list, are operations that are members of a
protocol, and affixing a constant prefix to each one of them, to remind
us what protocol they come from, makes sense.  This prefix need not
necesssarily have anything to do with any particular class/flavor that
implements the protocol.

    Most contemporary work in type theory and type inference conceptualizes
    types as collections of operations.  Intelligent type checking involves the
    computation of the minimal set of operations required for each parameter of
    each function to guarantee that no possible invocation can cause a "missing
    alternative for generic function" error.  Such sets are in general a
    subset of the complete operation set of a type.

In the sense of this paragraph, "type" means "protocol" rather than "class".

Now, Flavors does not have an explicit concept of a protocol right now,
and I don't think CommonLoops does as far as I know.  Instead, both
systems pretty much rely on the fact that there's usually some "abstract
class" that all implementors of the protocol are built on, and this
abstract class is what actually identifies and names the protocol.
Hence the convention that Gregor and Moon describe above.

(Speaking for myself.  I haven't discussed this previously with Gregor
and I apologize if I'm misrepresenting him.)