[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
hooks vs. subset (last try)
[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
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
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