[Openmcl-devel] DEFSTRUCT and :INCLUDE

[james anderson]

On 2009-10-14, at 10:55 , Tim Bradshaw wrote:

> On 13 Oct 2009, at 16:43, Daniel Weinreb wrote:
>
>> There are two separate questions here: what is the
>> definition of the Common Lisp language, and what
>> should CCL do?
>>
>> Regarding the former, I think I can say pretty reliably
>> that during the design of CL, nobody thought about
>> this.  So the spec is not written in such a way as to
>> give unambiguous guidance about what these forms
>> ought to do.
>
> I agree with this.  However I think it's clear that, if they had
> thought about it, they would not have mandated the kind of obscure
> accidental name-capture that CCL does (and which other implementations
> may well do as well), if only because it would give the hygienic macro
> people cause to poke fun at CL.
>
> I think one could argue from this text: "The slot default init forms
> are evaluated in the lexical environment in which the defstruct form
> itself appears and in the dynamic environment in which the call to the
> constructor function appears." that CCL (and some other
> implementations) are wrong.  However this is not clear enough since
> "the defstruct form" needs to be something like "the defstruct form
> which introduces the init form".

i do not read the spec to bear this out. while the passage with  
respect to default initargs in 7.1.3 does extend this environment's  
description, as in:

   The default value form is evaluated in the lexical environment of  
the defclass form that supplied it.

this passage is part of a separate text which discusses the  
interpretation of the default initargs, and does not benefit from  
being in the context of a specification for the interpretation of a  
particular definition form. the analogous passage in the  
specification of the defclass operator does not qualify the  
specification. that is, it suffices with the designation "the  
defclass form". i cannot recall any occasion to have wondered if i  
should even consider this to refer to anything other than the lexical  
context of the respective base class definition form.

>
>>
>> In a case like that, the CCL maintainers have to
>> give some consideration to the question of
>> whether introducing a new behavior that is
>> not consonant with other CL implementations
>> may be a drawback of a proposed change (to
>> be weighed among all the pros and cons).
>
> I also agree with this.  However I suspect strongly that the number of
> instances of code which defines structures which include other
> structures, which have init forms which capture names like this, *and*
> where the included structure was defined in a non-empty lexical
> environment is zero.  So the change would not affect any code.

you understate your argument. if one were to entertain to permit  
this, one risks promoting tolerance for the insidious in dynamic  
languages, cf. ruby.

>
> On the other hand the same argument says that this is fixing a problem
> which never affects any code, so why do it?

because one should be able to expect expressions in the language to  
specify coherent behavior.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20091014/4fcc9957/attachment.htm>