[r6rs-discuss] an essay on language design

From: William D Clinger <will>
Date: Wed, 11 Jul 2007 15:59:54 -0400

Kent Dybvig wrote:

> > * 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.

You are complaining about the "artificial restriction that
limits the procedural layer's preferred constructor-descriptors
to default constructor-descriptors." I said that "restriction
would be easy to remove also, but removing it might complicate
the optional expand-time or compile-time bookkeeping that
appears to have been the driving force behind the 5.97 design."

If you don't like the restriction, then remove it.

> > 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.

Granted. Relying on macros for performance doesn't work
very well. As explained below, the 5.97 syntactic layer
already has that problem. That is why the faster
implementations will rely on good representations,
supplemented by compiler optimizations. The simplest
implementations will rely on representations alone, which
will be plenty fast for their purposes.

> 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.

The procedural layer already provides accessors and mutators
that are analogous in complexity and efficiency to vector-ref
and vector-set! with offsets determined at closure creation
time. As Mike and I were discussing, the difference between
an offset determined at closure creation time and a constant
offset is at most one load instruction. There will seldom be
any difference at all, since implementations can special-case
small offsets.

You can't claim that the syntactic layer eliminates the much
larger cost of closure creation, or the cost of a closed call,
or the cost of checking that the record argument to accessors
and mutators is of a correct record type. The syntactic layer
is required to define the accessors and mutators in the normal
way, programmers are allowed to call them in the normal way,
programmers may assign new values to the variables that are
defined by the syntactic layer, and of course the records
themselves flow through programs in ways that macros cannot
analyze.

Only compiler optimization can eliminate the cost of closure
creation, closed calls, and run-time type checking, even with
the syntactic layer. The optimizations needed to do that are
essentially the same for both the procedural and the syntactic
layers. That is why most compilers will optimize neither or
both layers.

> The R5.97RS syntactic layer retains the desired property when the
> parent-rtd clause isn't used.

Which desired property is that? The use of constant offsets?

> 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.

The cost of a single load instruction, incurred only for
exceptionally large offsets, is unlikely to have a chilling
effect on the use of records.

If you are concerned about things that might have a chilling
effect on the use of records, then you should remove the false
statements that were inserted into the 5.97 draft to make
programmers think the procedural layer is likely to be slow.

True statements about the efficiency of the procedural layer
would have a reassuring effect.

Will
Received on Wed Jul 11 2007 - 15:59:54 UTC