William D Clinger <[EMAIL PROTECTED]> 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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
