[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DEFSTRUCT options syntax
- To: Common-Lisp at SU-AI
- Subject: DEFSTRUCT options syntax
- From: Alan Bawden <ALAN at MIT-MC>
- Date: Fri, 01 Oct 1982 08:06:00 -0000
From the last meeting:
17. Can we standardize on keywords always being used as
name-value pairs? The worst current deviants are
WITH-OPEN-FILE and DEFSTRUCT options.
Yes. The Lisp Machine LISP group will make a
proposal soon for OPEN, WITH-OPEN-FILE, and
While everyone agrees that OPEN and WITH-OPEN-FILE should be fixed (and they
already have been fixed on the Lisp Machine), the case for DEFSTRUCT is not as
clear. In my opinion the change is gratuitous since the options list in a
defstruct is NOT a function call. Furthermore it is more than a non-trivial
incompatible change since each option has to be re-thought in light of the fact
that it can now be given only one argument rather than any number. (Note that
the :CONSTRUCTOR and :INCLUDE options take advantage of this multiple-argument
I asked Moon and DLW if they agreed with me on this subject. Moon replied:
Date: Thursday, 30 September 1982 00:44-EDT
From: MOON at SCRC-TENEX
To: DLW at SCRC-TENEX
Re: gratuitous change to defstruct syntax.
I've changed my mind about this since August, and am now in agreement with
Alan. Partly this was caused by thinking about what it would mean to
change DEFFLAVOR to use alternating keywords and values; it seems very
clear that it would make it much worse. Thinking about this more made me
decide that some special forms have syntax that looks something like a
function call, but many are totally unrelated to function calls and trying
to wedge them into the same mold is just confused (and confusing).
Certainly the way OPEN used to be was wrong, and fixing it was a big win.
But I think DEFSTRUCT should stay with "option" or "(option args...)"
syntax, as should DEFFLAVOR, DEFSYSTEM, DEFSITE, and who knows what else.
It probably is not a coincidence that these are all "defining" forms.
DLW is also in agreement with me on this. How about it folks, can we keep
DEFSTRUCT parsing its options the way it is now?