[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:

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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]