[Openmcl-devel] [Re: MOP Question: structure of Lambda list for direct-slot-definition-class]

[Gary Byers]

On Wed, 23 Feb 2005, Marco Baringer wrote:

> Gary Byers <gb at clozure.com> writes:
>
> > On Mon, 21 Feb 2005 rm at fabula.de wrote:
> >
> >> On Mon, 21 Feb 2005 17:31:17 +0000, Bruno Haible wrote:
> >>
> >> > If you're using DEFCLASS, then the MOP says how slot
> >> > options should be handled (http://www.lisp.org/mop/concepts.html):
> >> >
> >> >   "All other slot options appear as the values of properties with the
> >> >    same name as the slot option. Note that this includes not only the
> >> >    remaining standard slot options (:allocation and :type), but also
> >> >    any other options and values appearing in the slot specification. If
> >> >    one of these slot options appears more than once, the value of the
> >> >    property will be a list of the specified values."
> >
> > The handling of MAG-STEP in the example in Figure 5.2 (AMOP p148) tends
> > to confirm the interpretation that the values of non-standard slot
> > options should only be collected into a list if they're provided multiple
> > times.
>
> i must be missing something. assuming that interpretation how would i
> distinguish between:
>
> (defclass foo ()
>   ((slot :value-type (ref something-else))))
>
> and
>
> (defclass foo ()
>   ((slot :value-type ref :value-type something-else)))
>
> the first form is valid, the second is an error. with openmcl's
> current behaviour i have no problems checking and reporting a
> meaningfull error, using clisp i can't tell the difference and my code
> happily excepts bad input.
>
> while i agree that this (listifying multiple values) is what the mop
> says i don't think it's the best way to do things.
>
> --
> -Marco

I don't believe that you're missing anything (if you are, I'm missing
it, too.)

I think that ideally I'd like to have some way of saying that a given
slot-option can appear at most once (as is true of some of the predefined
options) and that the associated value should be provided as is (well,
quoted), or that an option can appear multiple times and have the values
canonicalized into a list.

I agree that what the spec actually says (as reinforced by the example
in Figure 5.2) seems to be inferior to what I thought it said: option
values aren't canonicalized consistently, but that's a function of
the syntax of the call and not an attribute of the option itself (so
both cases have to be handled for every non-standard option, to the
extent that that's even possible.)

Implementing what the spec says would introduce an incompatible change
(and would, as you point out, likely make it hard to reliably validate
non-standard slot-option values.)  That's -almost- a compelling argument
against fixing it, but I'm not sure that it's quite compelling enough.

I do think that it may be worth considering having some way of requesting
the current non-compliant-but-more-consistent behavior (e.g., if
*DEFCLASS-ALWAYS-LISTIFIES-NON-STANDARD-SLOT-OPTION-VALUES* is true
at macroexpand time ...).  I keep thinking that the real solution is to
have something like:

(define-slot-option-behavior :value-type :at-most-once-and-single-value)
(define-slot-option-behavior :foreign-reader :allow-multiple-and-listify)

[The intent would be to define behavior that'd (a) take effect at
 DEFCLASS  macroexpand time and (b) be a global attribute of the symbol used
 as a slot option initarg.  If this could be reasonably implemented and
 used, I'd be less concerned about what the default behavior was.]