[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notes IJCAI mewtting of Common Lisp Object Committee
Notes from an informal meeting of the
Common Lisp Object Committee
International Joint Conference on Artificial Intelligence
Math Sciences Auditorium
UCLA Campus
22 August 1985
**Caveat: These notes were taken by Mark Stefik at the meeting for his
own purposes and were extracted from him under duress. These are not
official and are not necessarily representative of the opinion of the
Common Lisp Objects Committee, Xerox Corporation, the United States
Government, or the Blue Petunia Society. This summary has been checked
for accuracy only by the three speakers, Snyder, Drescher and Bobrow,
and with a few other randoms from Xerox. It is provided for the purpose
of stimulating discussion of what should be done next, and expansion and
clarification of issues discussed at the meeting (and hopefully not to
derail us into issues concerning the accurate or selective or
(un)balanced reporting of the meeting, or the official positions of
companies now, etc)
----
Richard Gabriel of Lucid opened the meeting with a few words about
Common Lisp, and the observation that there were various kinds of
unfinished business that have been recognized since the publication of
the silver book. One of the major areas of work is a Common Lisp
standard for object-oriented programming. The purpose of this committee
was to create recommendations for this standard.
Ken Kahn then spoke about the purposes of this meeting as follows:
o To present proposals for an objects extension to Common Lisp.
o To discuss the technical aspects of the proposals
o To begin a focused dialog in the objects subcommittee that
will continue beyond the meeting
He outlined the following for the next few months after the meeting:
o Continued discussion on the net
- Experimentation in the community with shared implementations
- Refinement and clarification of specifications
o Work towards a consensus on technical goals and specifications
o Prepare a recommendation for Common Lisp
The rest of the meeting was divided into two parts. In the first part,
three proposals for an object standard were presented in 20 minutes
each. In the last hour, the proposals were discussed.
---------------
The first proposal was presented by Alan Snyder of Hewlett-Packard. (He
declined to give his system a name, so it will be referred to as the
"Snyder proposal".) A printed version of the proposal is available from
Snyder. (snyder%hplabs@csnet-relay)
Snyder observed that "objects encapsulate interesting behavior". He
defined encapsulation as identifying constraints on manipulation and
user interface. He observed that although neither Common Loops nor
ObjectLisp say anything about encapsulation, either could get some
aspects of encapsulation by using the package system. However, that
style of encapsulation differs from the object-centered
encapsulation of traditional object-oriented languages, and has
problems supporting multiple representations and distributed objects.
Snyder identified the problem of encapsulating some of the information
in a super class from a subclass -- an idea not usually found in object
systems.
Snyder said that the notion of a "kernel" was by itself inadequate,
because it fails to provide for commonality in a community of users. He
identified some requirements of the community:
o Need code you can read
o DARPA wants code that can be maintained
o A portable implementation of an object dialect.
Snyder identified the following goals of his proposal:
o Language extension, not an implementation kernel.
o Common subset - base for nonstandard extensions
o Support and encourage object-oriented programming
o Include only well-understood features
o Avoid controversial features
o Avoid compromising capabilities for encapsulation
o Efficiency permitted for production code
e.g., direct access to instance variables w/o mapping tables.
He also identified the following features of his proposal.
o modified Flavors syntax
o object-centered encapsulation
o multiple inheritance
o support of class redefinition
o class-defined subtyping and equivalence
o concern for separate compilation issues
o language has been implemented and used.
He identified the following as missing from the proposal
o access to inherited ivs
o merging of ivs from inherited classes
o method combination
----------------------
The next presentation was Object-Lisp presented by Gary Drescher of MIT.
Drescher has licensed the system to LMI who is going to sell it.
Drescher was introduced by Dexter Pratt from LMI who said that LMI had
been recoding the window system in Object Lisp and were very happy with
it. Documentation of Object-Lisp is available from LMI.
The goal of Object Lisp is to make it be a rational superset of Lisp
used for all programming, not just a set of advanced features.
Status of ObjectLisp
o Pure Common Lisp implementation
o Available on Lambdas in September
o Inexpensive commercial license will be available
o Informal distribution will be encouraged for royalty-ree evaluation.
Objects are a set of bindings for methods and variables.
Objects reside in sets of nested environments.
Variables and methods are symetric.
Instance variables, class variables, instance functions, and class
functions can all be defined in the language.
Aside. This proposal seems very Scheme-like. But there is little
"declarative" sense of objects.
--------------------------
The next presentation was about "CommonLoops" by Daniel Bobrow of Xerox
PARC. Danny said the goals of CommonLoops were:
o Compatibility -- with Lisp programming.
o Small kernel -- easy to implement, understand.
o Powerful base -- for interesting applications.
o Universal kernel -- implement Flavors, Loops, Smalltalk, ...
-- next generation knowledge representation languages
o Efficiency -- no special hardware required.
CommonLoops unifies Lisp and Objects so that type=class (defstruct
extensions), slot=slot (same terminology), function~method (parallel
syntax), function call ~ message send (identical syntax).
He gave examples of defining classes and methods, and multi-methods. He
talked about how by defining many things as objects in CommonLoops, this
naturally provided hooks for extensibility
o Discriminator Objects e.g. load time protocols
o Method Objects e.g. compile time protocol
o Class Objects e.g. slot accss protocol
He gave an example of using CommonLoops hooks to implement Flavors-style
method combination.
o Flavors metaclass
- class precedence list
- slot-access methods
o Flavor discriminator
load-time protocol
o Flavor method
(implicit with notation for slots)
Danny described the CommonLoops kernel as containing
o defstruct extended for classes
o metaclasses
o defmethod like defun
o simple method combination (run-super)
CommonLoops extensions include a much longer list. (not included here)
***************************************************
Question Period
A lot of people raised questions. Some people I didn't know, and some
questions went by too quickly to take notes.
--
Martin Griss (HP): Isn't the issue we should decide whether or not we
want object oriented programming to look different, or not?
Bobrow: I think that it is more important to understand the various
proposals and what they make easy and hard than to start out with a
particular stand or take a vote on our current feelings.
--
Dave Dyers (Symbolics): Moon is working on a proposed new version of
Flavors that is very similar to CommonLoops. This is not official
Symbolics position, but I think CommonLoops is a good proposal, and
compatible with existing object languages.
--
JonL White (Lucid): The three panelists are all from the research
community. All the proposals are new. In the original Common Lisp
effort, there was 3-10 years of experience with the various lisps. None
of these has that. I like CommonLoops because it makes possible the
kind of variance and experimentation. Lisp's job is to absorb, rather
than to become.
Snyder: But CommonLoops does not support encapsulation.
Drescher: ObjectLisp is more conservative than CommonLoops because it
does not change the Lisp part of the language.
Bobrow: CommonLoops does not prescribe an approach to encapsulation, but
is not incompatible with having it. It's just not in the kernel. We
need to discuss the requirements for encapsulation over the net after
this meeting.
--
Touretsky (CMU): ObjectLisp throws away encapsulation. In CommonLoops
one could specify this on a per slot basis.
Drescher: It is possible that one could use packages to do
encapsulation.
Masinter: Packages have been the major encapsualtion mechanism inCommon
Lisp, and we should not invent new mechanisms if old ones do the job
well enough.
-------
Atardi: You have an opportunity now as you define objects to take into
account things that will be needed for parallelism in future machines.
To support concurrent execution should use something more like actors.
What you need is
o asynchronous send. [with continuation]
o synchronization methods (e.g., by locking objects)
Bobrow: This seems premature, and also not particularly specific to
objects. For example, one could have an asynchronous Eval.
Dyer: Current lisps don't handle concurrency well. But this is beyond
scope of this meeting.
--
Jed Harris (Intel): Alan Snyder's concern with encapsulation is valid,
but I'd want to make sure I could achieve it without sacrificing
efficiency.
Snyder: CommonLoops can implement anything. (so what!) The real issue
is, what do we provide the user. Packages may not provide good enough
encapsulation.
--
Halpern (IBM): Macro-expansions. When do they happen? I'm confused
about them and the Object-Lisp proposal.
Drescher: Macro-expansion happens at DEFOBFUN-time,
which is just compile-time for compiled code, DEFUN-time for interpreted
code (ie, macro-expansion semantics becomes the same for compiled &
evaluated code,
which seems like the right thing anyway, but that's another story).
Macro definitions are always global; you can't shadow them in objects.
What is not doable in ObjectLisp is running an interpreted function that
wants to macro-expand differently on different calls.
---
Bobrow: What I worry about in Object Lisp is the accidental capture of
names for functions. For example, if square-root is redefined in turtle
to work only in the domain of positive integers from 1 to 1000 (so it
can work fast by table lookup, say), then in a call to SINE, the wrong
square-root might be called. This would work better in a lexically
scoped system such as Scheme.
Drescher: That is a problem, but we haven't run into it.
--
Jonathan Reese (MIT): The question of what can be overloaded is
orthogonal ... The problem with Tell/Ask is a problem of modularity.
You don't want the caller (sender) to have to know whether things are
implemented as methods, or what.
--
JonL (Lucid): The issue is more than a technical one. We don't want a
technical revolution. We want the ability to change things
incrementally.
--
Pitman (Symbolics): I want to say a few things about each of the
proposals.
o I like the Snyder proposal for encapsulation. That's important.
Packages are clumsy in Common Lisp. They are hard to create, and hard
to move in and out of. It is important to get some support for data
abstraction that doesn't use packages.
o The Object Lisp proposal is hard to deal with because it changes the
scoping rules too drastically. Normal programmers will have trouble.
o CommonLoops is the first serious propoal which dispatches on multiple
arguments. That's an interesting idea.
--
Lieberman (MIT): Should messages be objects?
Bobrow: This can be implemented in CommonLoops to overloading the
"method-for" function in the funcall..
--
Carnese (Schlumberger): I want to raise a question of method
combination. Even though I wrote a thesis this thick on the subject
and did not come up with a satisfactory answer, it's important to users
and we should take a cut at simplifying the language of method
combination. We should try to find a right way.
There is also the issue of combinating of lexical and dynamic scoping in
Object Lisp. How will the compiler know whether it is in the object or
a free variable?
Drescher: All objects inherit eventually from some global context which
is itself an object.
--
Pitman: Isn't it a violation of data abstraction in Object Lisp to have
to know whether an object has a variable "x"?
--
Greenblatt: The primary feature of Object Lisp is the ability to add
variables after an object is in existence.
Bobrow: CommonLoops supports this through dynamic variables.
--
Snyder: I think that we should worry about the quality of error
messages.
--
Pitman: I suggest that CommonLoops needs a facility to say "I will
eventually defun x"
--
Greenblatt: We need to know whether the commonly called functions have
more than one method. I heard Bobrow's statistics, but those are static
and not dynamic measurements.
--
? (BBN): Speaking as a user, hurray for "with syntax" and method
combination.
--
? (Symbolics): CommonLoops is the main proposal which is in fact
addressing the needs of the user community. Compared with Snyder's
proposal, which is prescriptive; and ObjectLisp has not been concerned
about compatibility with other languages.
--
Pitman: It is important that the object language we adopt not prevent
us from working the way we do now.