Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE

[masinter.pa@Xerox.COM]

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


Issue:         DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References:    CLtL page 316
Category:      CHANGE
Edit history:  20-Sep-88, Version 1, Peck
		21-Sep-88, Version 2, Masinter, minor revisions


Problem description:

  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.

Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY

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.

Example:

  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)

Rationale:

This is a logical extension of the specification which makes some
programming easier.


Current practice:
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.

Benefits:
    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.

Esthetics:
    Minor improvement since it removes a needless restriction.

Discussion:

 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?  :-)