[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
- To: firstname.lastname@example.org
- Subject: Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
- From: masinter.pa@Xerox.COM
- Date: 21 Sep 88 01:02 PDT
This is Peck's proposal. I mainly edited it to put it in third instead of first
person, moved a few things around to fit the proposal format a bit better.
Subject: New issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
Currently, defstruct constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Allow combination of &OPTIONAL, &KEY and &AUX arguments in
constructor forms of defstructs.
The current wording in CLtL (p314):
"In addition, the keywords &optional, &rest, and &aux are recognised
in the argument list. They work in the way you might expect ..."
would be extended accordingly.
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
This is a logical extension of the specification which makes some
Some implementations to signal an error. Envos Medley (Xerox Common Lisp)
implements the proposed behavior.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Minor improvement since it removes a needless restriction.
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)