[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
partial results of Cambridge meeting
Here are some of my notes on things we decided at the meeting in
Cambridge earlier this month. I'm leaving out everything that is
specifically about meta objects, which was the bulk of the discussion.
This message is aimed just at finishing chapters 1 and 2. If there are
any disagreements, sing out. In cases where the documentation has
already been updated, I've noted that fact.
We decided to leave chapter 2 in its present format but add to its
introductory material a note that the present form of chapter 2 does not
attempt to address the division of a labor between what a generic
function does and what its standard methods do, and that that will be
changed in a later revision when meta-objects are finished. A few
things now in chapter 2 that really belong in chapter 3, such as the
descriptions of specific initialize-instance methods, will be moved.
We're all supposed to get in any final comments on chapters 1 and 2
as soon as possible, so that they can be mailed to the X3J13 committee
in January. I'll be sending mine in in a day or two.
For standard objects, EQL, EQUAL, and EQUALP are all the same as EQ.
Other equality functions treat standard objects the same as other
unrecognized objects, thus TREE-EQUAL uses EQL to compare standard
objects, and it is an error to use a standard object as an argument to
=, /=, CHAR-EQUAL, STRING-EQUAL, CHAR=, etc.
Add a :WRITER slot option and specify that
is an abbreviation for
:READER foo :WRITER (SETF foo)
This is already in chapter 1 (1-11), but with some editing mistakes,
which I'll send separate mail about.
Change the syntax of WITH-SLOTS to be like MULTIPLE-VALUE-BIND, by
interchanging the instance form and the list of slot names. Do not
provide a way to have more than one instance form in a single
SYMBOL-MACROLET definitely doesn't do anything special to the
macroexpansion environment, so a macro that's invoked in the body of a
SYMBOL-MACROLET (or WITH-SLOTS) cannot(emphasis!) tell whether a symbol
as a subform of an invocation of the macro is really a variable or is
going to get substituted. The remarks for SYMBOL-MACROLET thus recommend
that the forms should behave like variables, that is, reading should be
free of side-effects and evaluating either a read or a write multiple
times should be equivalent, except for speed, to doing it once. We
should supply examples of right and wrong ways to use SYMBOL-MACROLET.
(symbol-macrolet ((x (slot-value object 'x))) ...) ;good
(symbol-macrolet ((x (aref a (incf i)))) ...) ;bad, not idempotent
(symbol-macrolet ((x (aref a (1+ i)))) ...) ;good
(symbol-macrolet ((x (+ oldx offset))) ...) ;good, but read-only
(symbol-macrolet ((x (incf oldx offset))) ...) ;highly bad
(symbol-macrolet ((x (cons y z))) ...) ;bad, reading isn't idempotent
(symbol-macrolet ((x (caddr z))) ...) ;good
(symbol-macrolet ((x (throw 'tag))) ...) ;horrible
We don't have to use all these examples, I just quickly came up
with a bunch so there would be something to work from.
We discussed constructors for a while and I will send out a revised,
complete proposal in a couple days.