🚀 go-pugleaf

[Boy! this topic really seems to have opened up hasn't it?]

re: Bloody shame, then!  Alan Kay counts the lack of a consistent message
    nomenclature as one of the major failures of Smalltalk -- unless
    everybody uses the same names for the same operations, much of the
    power of message-passing abstraction is wasted.  CLOS itself provides
    no guide, and if even minimal compatability with the existing Common
    Lisp nomenclature, where relevant, is of no interest, one must conclude
    that CLOS is hell-bent on constructing an even more chaotic tower of
    . . .
    Which is, of course, precisely the problem.  So if you have a generic
    which does basically what AREF does, and you can't call it AREF, what
    *should* you call it?  Answer: Nobody gives a hoot, I gather. Whatever.
    . . .
    Yes, mom. But I didn't see the part in CLOS where it documents the
    generics to use for accessing/updating things which are semantically
    arrays, sets, relations... or DESCRIBE-OBJECT either, for that matter
    -- has someone renamed DESCRIBE recently?

A number of other replies to your response have covered much of the
territory, but I would like to put your question into focus by replying
about the goals of CLOS and X3J13, and how they affected the final design.

A most important point to remember is that we (the X3J13 committee as a
whole, and the CLOS subcommittee specifically) agreed that CLOS would be
an evolutionary step for Lisp, not a "revolutionary" one.  As Ken Anderson
eloquently put it, we wanted to make it easily possible to build CLOS in
Lisp, even though Lisp has not been excised of its historic, non-object-
oriented parts.  In fact, Lucid's 4.0 release (beta and product) has, for
over a year, been shipped as an optional "add on" submodule.  It works
perfectly well to mix and intermingle non-CLOS compiled code with that
subsequent compiled under CLOS.

Thus we explicitly decided that the compiler technology that supports
type declarations and optimizations derived therefrom, and that supports
"open-coding" for many primitive operations (i.e., not alterable after
compile time) -- well, that we wouldn't require the addition of CLOS to
dismantle all that machinery.  This is not a question of what an SSC can
or cannot do (i.e., a  "Sufficiently Smart Compiler"), but rather the
evolution of a Lisp community into the new "object-oriented" paradigms.
So except for where the "spec" turns old functionality into generic
functions, it must remain non-generic, and subject to all the old
optimizations and limitations.  [Barry Margolin has pointed out some of
the other, less obvious places (in addition to compiler optimizations)
where end-user code might depend upon the existing limitations.]

If you accept that as the status quo for the next period of time (i.e.,
until there is another revision of the ANSI Common Lisp proposal), then
your question about why we didn't take on more of a job at specifying
extended functionality for CLOS is still valid.  For example, why didn't
we add new generic functions approximating what the CL sequence functions
do? such as a generalized AREF and/or ELT?  There are two answers here.
The short, simple one is that in fact the committee bit off more work
that it could chew, and fleshing out all the possible protocols that
might make Alan Kay happy was, frankly, beyond the limits of time
available to do a good enough job.  A more fundamental answer is that
this is "new territory", and the X3J13/ANSI effort was intending to
be a standardization effort with direct applicability to existing
commercial implementations of Common Lisp -- not a research project
into the corners of object-oriented languages.  We simply could not
standardize any "new wine" before its time.

However, some work has proceeded after the time (in September 1988) of
the publication of the CLOS specification.  For example, you have asked
"... has someone renamed DESCRIBE recently?"  The answer is no, DESCRIBE
wasn't renamed; but its definition was redefined to call a new, generic
function named DESCRIBE-OBJECT.  X3J13 understood that as "safe" and
desirable step and accepted it in March 1989.  If you look at CLtL/II,
pages 697-8, you'll notice that Steele refers to the X3J13 issue #63
(the index numbers are Steele's) where this was changed.

On the other hand, several of the most common requests from the user
community for genericification were explicitly rejected: (1) to have a
generic COPY function, (2) to have a generic equivalence predicate,
possibly even named EQUAL, and (3) to have generic hash-tables that can
accept any equivalence predicate in addition to the three or four currently
listed, (4) to have some new generic functions underlying the use of
streams, and (5) to have the "holy grail" of CLOS, namely a metaobject
protocol interface.

All of  these were rejected (or tabled indefinitely) by a majority of
X3J13, primarily because the open design questions were deep enough and
broad enough that we just wouldn't be able to  reach consensus on any of
them in the time period available (i.e., before 1990).  As Gregor Kiczales
noted, the rejections by X3J13 don't mean these topics are inherently
wrong or undoable -- but just that we likely won't have consistent,
portable interfaces to the subparts that the individual vendors do.
[Although there is some hope that Lucid, Franz, and Symbolics will reach
an informal agreement about supportable subparts for some new, generic
stream functions and for some metaobject protocols.  Incidentally, Lucid's
stream system, since 1987, has been object-oriented and CLOS-like, but
certainly much less than, and not integrated with, CLOS; it has been
documented in the "wizard's, on-line documentation", with the expectation
that someday it would be replaced by a true CLOS interface.]



-- JonL --