Hi Ludovic! l...@gnu.org (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
