William D Clinger <will at ccs.neu.edu> writes:
> Although the editors acted with the best of intentions,
> their addition of the parent-rtd clause did not solve
> the problems it was intended to solve. Even with the
> parent-rtd feature, you *still* have to know whether
> the base record type was defined using the syntactic
> or record layer
I conjecture that this is true for many reasonable designs of record
layers built on top of the procedural record layer from the candidate
draft. (This has nothing to do with whether they layer is syntactic or
not.) For example, a perfectly reasonable addition to the procedural
layer would be functional updaters, which could support the same modular
construction as the constructors. It may make perfect sense to package
functional updaters together with the other information about a "record
type". What's important is that there's some way to get at the rtd.
> In future releases, an unoptimized record access will
> consist of a procedure call, a double tag check, an
> indirect load, an eq? check, and a load. Twobit's
> existing optimizations, or easy extensions of them,
> will eliminate any or all of that code when it is safe
> to so.
I am curious how that works. (And I don't mean that in a sarcastic
way.) I assume the procedure call mentioned above is the call to the
closed version of the record accessor. Eliminating that procedure call
and also inlining the index into the record object (so it can be used to
generate an instruction using that index) was the first concern you
voiced when the two of us talked about records in May 2005. The
implementation of SRFI 9 in Scheme 48, for example, achieves this by
computing the index at macro-expansion time (and bypassing its own
procedural layer). Of course, this is always possible because SRFI 9
doesn't support record extension, and therefore all information needed
for this is available at macro expansion time.
This seems hard to achieve with the procedural layer, as it can
presumably only use a finite number of lambdas to represent the
accessors for a potentially infinite number of record indices. It's
unclear to me how to do it without a successful flow analysis if the
syntactic record types are merely the run-time record types: If the
record types of the syntactic layers are merely run-time identifiers
referring to rtds, and as the indices in child types depend on parent
types, it seems to me you need to defer computation of the index until
run time, presumably requiring at least an extra instruction to load
that index. (Also, I suspect you need a better inliner to handle the
extra indirection through the procedural layer.) I suppose one could
associate different objects with the record-type identifier at
macro-expansion time and run time (someone who understands this better
than I could maybe confirm), but this may be quite confusing.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Wed Jul 11 2007 - 03:34:26 UTC