jonl@LUCID.COM (Jon L White) (02/15/91)
Skip, your critique of the alleged Symbolics statememnt on metaclass
capabilities seem a bit too strong to me. Let me offer some mild
support for the alleged symbolics position, and see whether or not
your reply is really directed towards their real position.
1) The errors emanating from MAKE-INSTANCE in jkelly's case were
*probably* not the intended behaviour of Genera 8.1 (someone else
may correct me if I'm wrong); I would interpret the Symbolics
customer support statements as trying to provide a workaround for
this situation -- if it "hurts" when you bend your elbow like this,
then don't bend your elbow like this -- the same end-user results
may be achieved with non-metaclass programming. [And hopefully,
your next android model won't have a squeaky elbow.]
2) 2a) there is no "THE" metaobject protocol;
2b) but there are numerous proposals for metaobject protocols;
2c) and there are many more actual "metaobject" protocols -- for
clarification as to why there MUST be many, see 2e below;
2d) the writers of the CLOS proposal to X3J13 (the "Chapters 1
and 2" draft widely reprinted in Sigplan Notices in Sep 1988,
and in CLtL/II) were fully expecting that an acceptable amount
of metaobject specifications would be forthcoming in the
subsequent "Chapter 3"; sigh, the best laid plans of . . .
Note that some "Chapter 1 & 2" parts don't really make much
sense without more of what might have been included in
"Chap 3" (e.g., ADD-METHOD); and other parts of "Chap 2"
appear to have been dropped or omitted possibly out of a
mistaken belief that they weren't useful without "Chap 3"
(e.g., ALLOCATE-INSTANCE, which is critical to good use
of MAKE-LOAD-FORM; for the latter, see CLtL/II p.659)
2e) as the symbolics implementor mentioned, what is popularly
*thought of* as "Chap 3" is very PCL specific, and would
likely have to undergo many changes before being acceptable
as any kind of community standard. The reason why these early
versions HAD to be PCL specific is that the very essence of
"metaobjects" is that they are the objects needed to implement
the system. Just what is "necessary and good" to implement CLOS?
Well, as you suggest, a turing machine is adequate; but certainly
not desirable (can you imagine at Turing Machine Protocol!)
As more implementations of CLOS become known, and as more
users of CLOS press their demands for system tailoring, then
we as a community will begin to see just how far we can go to
specify a "metaobject protocol" without unduly crippling the
underlying implementational technologies. To put this question
into perspective, I refer you to one of the earlier issues of
Lisp Pointers, to an article proposing some standards for Lisp
Interpreter interfaces -- it went by the name COMMON EVAL. The
critique against it was that it specified far too many irrelevant
details as to how any intepreter must work; the critiques also
were that it was specification via a piece of Lisp code rather
than by a set legalistic English sentences (i.e. it was too
metacircular). But it very clearly showed up the real problem of
"metaobject" protocols -- that one is fighting a battle on the dual
fronts of permitting the end user access to the implementation
details at some level, yet shielding him from the accidental coding
kludges used by some one individual implementor.
To resovle this issue -- of just "what" and "how much" would be desirable
as a CLOS metaobject protocol -- more people need to understand the issues
involved in implementing a CLOS. In recognition of the fundamental nature
of this need, I applaud the work of Gregor Kiczales, Jim Des Rivieres, and
Danny Bobrow of Xerox PARC in producing a book(?) which presents a limited
subset of CLOS and an implementation therefor in an understandable way (it
is called CLOSSETTE -- a little CLOS perhaps?). While the actual code for
this limited system may not be practically useful, it is of great
pedagogical value.
In the meantime, there are in fact some "de facto" standards in common
use for metaobjects. They are by no means complete, but do offer some
degree of stabililty. Explicitly, I refer to a mail message sent out
just about a year ago to the X3J13 email list detailing the three or four
dozen "metaobject protocol" functions and classes that Lucid and Symbolics
were agreeing to support. Dave Moon sent the message, and it represented
some behind the scenes work between him, myself, and Scott Cyphers at
Symbolics (Dave may have contacted other vendors, but I'm not directly
aware of what their responses were.) Virtually all of the functions and
features were drawn from previous versions of "Chapter 3" drafts, and
represent merely an "introspective" set (i.e., generic accessor-like
functions to fetch components of the major metaobject classes -- CLASSes,
GENERIC-FUNCTIONs, METHODs, and SLOT-DEFINITION's)
Given all this background, I would hope that one could sift the metaobject
wheat from the chaff; that one could resist the attempts by the hucksters
of "Fly-by-Night Lisp, Inc" to sell you on their ONE TRUE (Relig... oops,
I mean) Metaobject Protocol; and that we all would go a little easier on
the likes of Symbolics.
-- JonL --