hooks vs. subset (last try)

[Snyder%hplabs.csnet@csnet-relay.arpa]

[If you have already seen this message, I apologize.  Since I never received
it back from the mailing list, I am assuming it got lost somewhere along
the way and am sending it again.]

I would like to argue against the proposal that we concentrate on "defining
hooks into Common Lisp for implementing Flavors, Loops, and the like".
Although this is a worthy activity, I believe it would be more appropriate for
this group to attempt to define an extension to Common Lisp that can be used
by Common Lisp programmers who wish to program in an object-oriented style.

The charter of this group is to propose extensions to Common Lisp to support
object oriented programming.  This group was created at the Monterey meeting
because the attendees felt that the area of object-oriented programming was
the most important area in which extensions to Common Lisp are required.  (The
other popular areas were error handling, foreign function call, window
systems, and graphics.)  The attendees did not state specifically why they
thought that extending Common Lisp to support object-oriented programming was
so important.  In deciding which approach to follow, we should consider what
their (and our) desires are.  We should also attempt to consider the desires
of the larger Common Lisp community, i.e., the potential users of Common Lisp,
not just the designers and implementers.

Here are a number of possible paraphrases for the statement "I believe that
Common Lisp should be extended to support object-oriented programming".  Which
do you agree with?  How strongly?  Which do you believe the implementors of
Common Lisp agree with?  Which do you believe the Common Lisp user community
would agree with?

1. I have one or more programs written using Zetalisp flavors and I want them
   to run on any Common Lisp implementation.  (Questions: Do the programs use
   other features of Zetalisp that are not in Common Lisp?  Can such features
   be implemented using portable Common Lisp code?  How will users of your
   programs ensure that those features are supported in their systems?  Do you
   care how efficient the implementation of Zetalisp flavors is on any
   particular Common Lisp?)

2. There exist one or more programs written using Zetalisp flavors that
   I want to run on my Common Lisp.  (Questions: same as previous.)

3. I like using Zetalisp flavors and want to be able to use it when I write
   Common Lisp code.  (Questions: Do you care how efficient the implementation
   of Zetalisp flavors is on the Common Lisp you are using?  Do you care
   whether the Common Lisp programming environment you are using knows
   anything about Zetalisp flavors?)

4. I don't know much about Zetalisp flavors, but I would like to experiment
   using it on my Common Lisp system.

5. I have one or more programs written using LOOPS and I want them to run on
   any Common Lisp implementation.  (Questions: Do the programs use other
   features of Interlisp that are not in Common Lisp?  Can such features be
   implemented using portable Common Lisp code?  How will users of your
   programs ensure that those features are supported in their systems?  Do you
   care how efficient the implementation of LOOPS is on any particular Common
   Lisp?)

6. There exist one or more programs written using LOOPS that I want to run on
   my Common Lisp.  (Questions: same as previous.)

7. I like using LOOPS and want to be able to use it when I write Common Lisp
   code.  (Questions: Do you care how efficient the implementation of LOOPS is
   on the Common Lisp you are using?  Do you care whether the Common Lisp
   programming environment you are using knows anything about LOOPS?)

8. I don't know much about LOOPS, but I would like to experiment using it on
   my Common Lisp system.

9. (Similar questions for any other object-oriented Lisp extension.)

10. I want to use an object-oriented style of programming, but recognize
    that there is no consensus on the details of object-oriented programming
    constructs.  Therefore, I want to be able to use various (existing or not
    yet invented) objects systems in Common Lisp to help determine what the
    "right" one is.  Since each programmer individually chooses which objects
    system to use, it is necessary that all objects systems run concurrently
    in the same system to allow sharing of code written by others.

11. I have my own favorite objects system, but other people have different
    ideas.  The best way to get my favorite objects system to run in Common
    Lisp is to ensure that the necessary hooks are a standard feature of every
    Common Lisp implementation.

I am sure that for each of the above statements, there is some fraction of the
Common Lisp community that strongly agrees with the statement.  I agree with
some of them, too, but I don't consider them top priority.

Below is my paraphrase of the above statement. I believe this statement is one
that many (potential) users of Common Lisp would agree with, but unfortunately
they are not "here" to express an opinion.  I also speculate that many of the
attendees at the Monterey meeting that supported the creation of this
committee did so for this reason.  (How many of said people are listening to
this discussion?  I would like to know if you agree or disagree.  Perhaps we
should raise this issue in the larger Common-Lisp mailing list, or by USmail
to the Monterey attendees.)

--------------------------------------------------------------------------------

12. I believe that object-oriented programming is "standard practice" for a
    large part of the programming performed by myself and my colleagues.  It
    is as fundamental in my programming as functions are in traditional Lisp
    programming.  I wouldn't want to write code any other way.  I believe that
    the object-oriented style of programming is valid and useful for both low
    level systems coding (such as implementing I/O or a window system) and
    high level applications.  For these reasons, I believe that no general
    purpose programming language (including Common Lisp) is acceptable unless
    it allows me to program in the object-oriented style.

    As a user of Common Lisp, I therefore expect to find object-oriented
    programming constructs available to me.  I expect these constructs to be
    sufficiently efficient that I am not dissuaded from using them because of
    poor performance.  I expect these constructs to be understood and
    supported by the programming environment (the Common Lisp editor and
    debugger) provided as part of my Common Lisp development system.  I expect
    these constructs to be documented in the documentation that comes with my
    Common Lisp system.  I expect any book on Common Lisp to teach me how to
    use them.  I expect the manufacturer of my Common Lisp system to
    understand these constructs; if I have a problem, I expect the
    manufacturer's representative to be able to help me.  I want any
    proficient Common Lisp programmer to be able to understand and maintain
    code written using these constructs.

    Although I have used various object-oriented languages, I understand that
    Common Lisp may not use my favorite syntax or provide my favorite feature,
    just as it differs from other Lisps in its syntax and feature set.  I
    accept these limitations in a desire to have a "common" Lisp used and
    understood by many people.

--------------------------------------------------------------------------------

Thus, I do not consider object-oriented programming to be in the same category
as AI knowledge representation systems (Moon's example) or logic programming,
or any of a number of ideas that cannot yet be considered "standard practice"
for a wide range of programming tasks.  Here the Monterey attendees apparently
agree with me, as they did not endorse an immediate need for Common Lisp
extensions to support AI knowledge representation systems, logic programming,
or even multiprogramming.  (I was impressed with the ability of that large
group to focus on a small number of areas where extensions are urgently
required.)

I strongly doubt that defining only a set of hooks as a standard part of
Common Lisp will achieve the objectives of efficiency and support listed
above.  Given the finite resources available to any manufacturer (or author,
for that matter), we cannot expect a manufacturer to support a nonstandard
objects system unless it becomes a de facto standard because of widespread
demand in the market.  We certainly cannot expect manufacturers to support
multiple competing objects systems.  If Common Lisp is to have a supported
objects system, agreement must be reached on a single standard.  If we cannot
agree, who can?

Furthermore, it has yet to be shown that a set of portable low-level hooks
exists that can efficiently implement any one of the existing objects systems
on all Common Lisp implementations, much less all of them.  I also doubt very
much that multiple coexisting objects systems can be efficiently supported.
Others have expressed similar doubts: Moon: "I've had enough experience with
both of these to know that it won't be easy ..." Fahlman: "... even this is
not an easy problem for several reasons".  Handerson: "There will probably
have to be more than one substrate used by different objects systems, and
quite possibly every major object system will have its own."

Obviously there is a conflict between my claim that the object oriented style
of programming is "standard practice" and the widespread belief that years of
further experimentation will be required before the "right" object system is
designed.  My belief is that there is a common kernel that we can all agree to
(probably roughly equivalent to Smalltalk) and that defining such a kernel as
a standard component of Common Lisp is most beneficial to the Common Lisp
community at large.  If we think we can agree to a set of hooks, could we not
also agree on a set of constructs that are based on those hooks?

  -- Alan Snyder
-------