> If I were designing this thing, and were not constrained
> to remain compatible with the features that have already
> been piled on, I would remove the restriction by
> eliminating the preferred constructor descriptors.
As long as we're contemplating changes, we might as well contemplate
fixing the thing completely. I'm interested in what you would propose if
not constrained.
> I have investigated this matter pretty thoroughly,
> and your claim above concerning the cost of safety
> checking shows that you do not yet understand just
> how fast the procedural layer can and should be.
None of what you say is news to me. With regard to the safety check, I
was talking about the extra load needed to extract the <magic> object for
comparison from the generated closure in the unoptimized code. I'd
forgotten that this can't be avoided in R5.96RS even for the syntactic
layer unless the nongenerative clause is present, because of the
requirement that two evaluations of the same define-record-type must
otherwise produce different types.
In any case, all of what you say is interesting and should be useful for
compiler writers who wish to optimize certain controlled uses of the
procedural layer. For those that don't want to build the various
high-level record operations into their compilers or interpreters, along
with the optimizations needed to eliminate the extra overhead, my point is
that the syntactic layer should permit direct macro-generation of
efficient code (that is, code on par with vector-based abstractions and
amenable to the general-purpose inlining that many compilers already do).
The R5.96RS syntactic layer permits this; the R5.97RS syntactic layer
permits this when the parent-rtd clause isn't used; and your proposed
extension would permit this if the <parent name> variable were immutable.
I prefer that it be immutable regardless of whether the definition appears
at the top level of a library or program body, since I quite often use
record definitions internally.
Kent
Received on Thu Jul 12 2007 - 10:39:22 UTC