[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Functional record "setters", a different approach
From: |
Mark H Weaver |
Subject: |
Re: Functional record "setters", a different approach |
Date: |
Fri, 13 Apr 2012 13:26:29 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Hi Ludovic!
address@hidden (Ludovic Courtès) writes:
> I’d say ‘set-fields’, no?
Okay, good enough.
>>> Would these checks be alleviated by Andy’s work on peval “predicates”?
>>
>> Unfortunately, no. The 'vtable' field of a struct is a mutable field,
>> and in fact when a GOOPS class is redefined, the 'vtable' field of
>> instances are modified. This means that it is not safe for the compiler
>> to eliminate redundant calls to 'struct-vtable'.
>
> Oh, OK. That is eviiiil.
It turns out that I had some misconceptions about this. Although it is
true that the first word of a struct cell is mutated, that's actually
not what 'struct-vtable' returns nowadays. Class redefinition involves
a rather complicated dance described here:
http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile
So, the result of 'struct-vtable' does not change after all, at least
not for plain instances. (It's not yet clear to me whether the vtable
of a redefined class object itself can be changed).
Regardless, 'struct-vtable' checks usually involve comparison with the
value of a mutable top-level variable, and of course the compiler must
assume that mutable variables might change whenever unknown code is run
(e.g. when any top-level procedure is called).
>> This example is intended to convince you that 'nocheck' variants of
>> struct accessors are important as a base upon which to build efficient
>> higher-level constructs, at least for our own internal use.
>
> I view it as an important “implementation detail”, but not as an API to
> be exposed publicly.
>
> What about keeping it private until we find an actual use case where it
> is required outside of (srfi srfi-9)?
Okay, fair enough :)
Thanks,
Mark
- Functional record "setters", a different approach, Mark H Weaver, 2012/04/11
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/04/11
- Re: Functional record "setters", a different approach, Ludovic Courtès, 2012/04/11
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/04/12
- Re: Functional record "setters", a different approach, Thien-Thi Nguyen, 2012/04/12
- Re: Functional record "setters", a different approach, Ludovic Courtès, 2012/04/12
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/04/12
- Re: Functional record "setters", a different approach, Ludovic Courtès, 2012/04/13
- Re: Functional record "setters", a different approach,
Mark H Weaver <=