[Openmcl-devel] DEFSTRUCT and :INCLUDE

Ron Garret ron at flownet.com
Wed Oct 14 10:13:59 PDT 2009


Speaking only for myself here:

I agree that in and of itself this is not a very important technical  
issue in the grand and glorious scheme of things.  But when arguing  
for Truth, Justice, and the Lambda Way, it helps to be able to point  
to an implementation and say, "See, this implementation does it this  
way."  It's not a logically valid argument, but it carries weight with  
many people nonetheless.  (Andrew, if you're lurking, this is a  
clue.)  In the long run this can be beneficial because it establishes  
reasonable precedents which can help when controversy arises over more  
substantive issues.  Think of it as a geeky version of the broken  
windows theory.

rg

On Oct 14, 2009, at 9:50 AM, Alexander Repenning wrote:

> just curious, why even still use defstruct and not just CLOS. If one  
> does not need byte aligned data for low level data structures or to  
> squeeze out the last nano second for accessor is there some  
> compelling reason to even keep using CL structs?
>
> I usually advise students to ignore structs because they are mostly  
> obsolete.
>
> Alex
>
>
> On Oct 11, 2009, at 5:22 AM, Tim Bradshaw wrote:
>
>> There has been some discussion on CLL about what happens with init
>> forms for structures defined in lexical environments, particularly
>> included structures.
>>
>> I am not sure if the standard is precise enough about this, but I
>> think CCL gets it "wrong" (where "wrong" means "not what I
>> expected"...).  Consider something like this:
>>
>> (let ((x 1))
>>   (defstruct bog
>>     (a x)))
>>
>> I think that, clearly
>>
>> (= (bog-x (make-bog)) 1)
>>
>> Not what about this:
>>
>> (defstruct (bat (:include bog))
>>   (b 3))
>>
>> I think that the same thing should hold.  What CCL does is signal a
>> warning at compile time, and an error at structure creation time.  In
>> other words, what it's doing is reusing the source form from the
>> included structure, not the compiled initform (which closes over X).
>>
>> Now what about this:
>>
>> (let ((x 4))
>>   (defstruct (fat (:include bog))
>>     (b 3)))
>>
>> I think that (= (fat-x (make-fat)) 3) should hold, but now it is 4
>> (presumably for the same reason as above).  This strikes me as
>> incredibly counter-intuitive, which is why I think CCL is wrong here.
>>
>> Finally:
>>
>> (defstruct (splat (:include bog
>>                             (a 4)))
>>   (b 3))
>>
>> CCL gets this right.
>>
>> So I think there is some underlying issue that, when including a
>> structure in another one, CCL is using the source of the initforms,
>> when (I think) it needs to, at the point where the original structure
>> is defined, stash a closure for the initform, which it can then call
>> if the structure is included in another one.  It only actually  
>> *needs*
>> to do this is there is a non-empty lexical environment, and I guess  
>> if
>> that can be detected then it can safely reuse the source in most  
>> cases
>> as that will probably make structure creation faster.
>>
>> --tim
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> Prof. Alexander Repenning
>
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
>
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

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


More information about the Openmcl-devel mailing list