Re: Functional record "setters", a different approach

[Mark H Weaver]

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