References: CLtL p.50
Related issues: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Edit history: 29-Apr-90, Version 1 by Moon
30-Apr-90, Version 2 by Moon (update current practice)
4-May-90, Version 3 by Moon (update from comment received)
9-May-90, Version 4 by Moon (revise according to comments
received. Specifically, remove references to
&ENVIRONMENT, take no stand on destructuring, and
correct the current practice.)
CLtL p.50 only mentions &OPTIONAL and &REST as allowed lambda-list
keywords in DEFTYPE. It doesn't say whether &KEY is allowed too.
This is Symbolics issue #18.
Allow &OPTIONAL, &REST, &KEY, &ALLOW-OTHER-KEYS, and &AUX in the
lambda-list of DEFTYPE.
Clarify that unsupplied keyword arguments default to *, not NIL, the same
as unsupplied optional arguments, if no initform is specified in the
lambda-list. &AUX parameters are initialized to NIL if no initform is
(deftype xarray (&key dimensions (rank '* rank-p) element-type)
(check-type rank (or (member *) (integer 0 *)))
(check-type dimensions (or (member *) list))
,(if rank-p rank dimensions)))
(check-type z (xarray :rank 2 :element-type double-float))
(define-presentation-type command (&key (command-table *command-table*))
define-presentation-type is similar to deftype but defines some
additional information about use of the type in user interfaces.
Type specifiers with keyword arguments are used extensively in CLIM
and CLIM-based applications.
&AUX is allowed just for completeness.
Symbolics Genera 8.0 supports the proposal.
Lucid 3.0.1 signals an error (&KEY not allowed) for this example.
Franz Allegro CL 3.1.beta.22 supports the proposal.
Other implementations were not surveyed.
Cost to Implementors:
Should be small since this simply makes DEFTYPE support the same
lambda-list keywords as DEFUN and LAMBDA (which suggests an
implementation technique of inserting '* where an initform is not
specified for an &optional or &keyword argument and then making a
function that is applied to the cdr of the type specifier).
Cost to Users:
Cost of non-adoption:
CLIM will not fit into Common Lisp as well. DEFTYPE will be less
consistent with the rest of the language.
Cost of non-adoption will not be incurred.
DEFTYPE will be consistent with DEFUN, eliminating an arbitrary
There has been some discussion about whether DEFTYPE supports
destructuring. It seems that CLtL pages 50 and 146 may contradict
each other on this point. This issue explicitly does not address
the question of destructuring.