Re: accessor functions

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

    Date: Fri, 25 Jul 86  10:54:13 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Even better would be DBG:CONDITION:STATUS and DBG:CONDITION:TYPE I would
    think (if such a thing were legal).

In fact, the package system the Alan Bawden and I designed and
implemented for the MIT Lisp Machine system, which was superseded by the
present Common Lisp package system, did have exactly this functionality.
I believe it was removed during the Common Lisp redesign in the
interests of simplicity.  However, as time goes on, I've been wondering
whether that was such a good idea.

	In any case, I think this is the same issue that arises with non-generic
	function naming, and doesn't have anything to do with genericness (with
	object-oriented programming) per se.

    There are many cases where the introduction of object-oriented programming
    tends to focus attention of existing problems in Common Lisp.  The package
    system is probably the worst offender.  However, if you are implying that
    because these problems are already in Common Lisp we should not worry about
    them now, I disagree.  The interactions with object-oriented programming make
    it especially important that these problems be fixed now.

I didn't say that we should not worry about them.  I only said that the
problem isn't specific to object-oriented programming.  And I'm not
convinced yet that interactions with object-oriented programming
particularly exacerbate the problem, since I think the problem is just
as real even if you program with ordinary functions and defstructs.  In
any case, if you have a proposal for an improvement that you think could
be introduced into Common Lisp under the current set of ground rules
(see recent Fahlman mail), you should go ahead.

    I agree completely.  Why then is there a conc-name feature (with a particular
    default) for automatically generated functions and not for those explicitly
    written?

Well, if defflavor is going to generate functions automatically, it has
to call them something.  If we are going to encourage a programming
style in which you can make up your own names for instance variables as
easily as you can make up your own names for lexical variables (note
that careful phrasing), then using those instance variable names as
function names is hazardous, because the naming world of function names
is a package (broad), whereas the naming world of an instance variable
is only a set of comixed flavors (narrow).  If we assumed a much finer
granularity for packages, then perhaps the default conc-name feature
would not be appropriate.  I guess this is what you mean about the
particular interaction of OOP and the use of packages.

This leads into a pretty deep issue of what packages are about, and what
spaces are of names are for in general and how various naming mechanisms
interact in a language.  I could go on for a long time disussing my
thoughts on this topic, but I'm not sure that would do anybody any good.
Let me just say that changing packages to the point where the conc-name
would not be the appropriate default would be a truly massive change in
the nature of what packages are for and how they are used.  It would
have very wide implications, and might require a lot of other changes to
the language.  I obviously cannot comment on a proposed change that has
not been proposed, but in my opinion it would be a big thing, not a little
thing.