> * In consequence, the code you write for a record type > definition that inherits from some base type depends > upon whether that base type was defined using the > syntactic or procedural layer. > > * Record types defined by the syntactic layer are not > interchangeable with record types defined by the > procedural layer.
This remains true even with your proposal whenever a constructor descriptor other than the equivalent of (make-record-constructor-descriptor rtd <parent-preferred> #f) (where <parent-preferred> is #f if there is no parent) is used. For example, if one converts a syntactic definition that specifies a protocol into the equivalent using the procedural layer, the resulting preferred constructor may be different. In R5.97RS this can occur only if the parent clause is used. With your proposal the problem becomes more insidious. In both R5.97RS and with your proposal, the rtd resulting from a use of (record-type-descriptor <record name>) can be used in exactly the same manner as an rtd created via the procedural layer. > The only additional complication of my > proposal is that the macro expander and/or compiler > would have to recognize when the <record name> is > an expression other than a variable that was bound > by define-record-type. Recognizing that is trivial. If the <parent name> variable bound by define-record-type is an ordinary mutable variable, any expand-time information associated with <parent name> is useless to a macro implementing define-record-type, since it has no way of determining if the variable is actually assigned. The R5.96RS syntactic layer was intended to allow a macro implementation of define-record-type to expand into constructor, accessor, and mutator definitions that use internal record construction, access, and mutation primitives that are analogous in complexity and efficiency to vector, vector-ref, and vector-set! (the latter with constant offsets), although the editors have done a poor job of communicating this. The idea behind this is to make abstractions built using define-record-type roughly as efficient as abstractions built using vectors, and not just in systems with sophisticated compilers. Otherwise, users of interpreters and less sophisticated compilers may be tempted to use vectors instead of records where records are more appropriate. While it's possible that most compilers will optimize neither or both the procedural and syntactic layers, as you claim, I think it's likely that most implementations will produce better code for the syntactic than procedural layers---provided we don't screw the syntactic layer up too badly. The R5.97RS syntactic layer retains the desired property when the parent-rtd clause isn't used. Your proposal retains the desired property if parents are <parent name>s bound by define-record-type and the <parent name>s are immutable. Otherwise, additional overhead will be introduced that a given implementation may or may not be able to eliminate, and our goal of making records approximately as expensive as procedures defined using vector primitives will not always be met. Whether this will have a chilling effect on the use of records remains to be seen. Kent _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
