ludo@... (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)?