> * 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
Received on Wed Jul 11 2007 - 13:43:49 UTC