No subject

    Note:  Use of the parent-rtd clause generally
    forces an implementation to delay the generation
    of constructor, accessor, and mutator code until
    the record-type definition is evaluated at run
    time, since the type of the parent is not generally
    known until then.

That is a false statement.  The editors might as well
claim that the code for a lambda expression cannot be
generated until run time, since the values of its
free variables will not be known until then.

Even in the current release of Larceny, all of the code
generated for constructors, accessors, and mutators is
generated at compile time.  None of that code is ever
generated at run time.

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.

The code that isn't eliminated by optimization will
be generated at compile time.  No code will ever be
generated at run time.

And that's for the procedural layer.  There is no
earthly reason for a compiler to generate worse code
for the syntactic layer than for the procedural layer,
or to generate it any later.

    The parent clause should therefore be used instead
    whenever possible.

This recommendation is based upon a false premise.

So What?
========

The substantive changes that were made in the 5.97
draft are immune to meaningful technical review, so
why did I write this?  Partly to blow off steam, of
course, but there were at least three other reasons
as well.

As Andre van Tonder wrote, the only way for us to
register disagreement with changes made in the 5.97
draft is to vote against ratification [9].  Under
the rules of that vote, any negative vote must be
accompanied by an explanation, so I had to write
something like this anyway.

I am told that, if this draft is not ratified, the
Steering Committee intends to pay a lot of attention
to the reasons cited in those explanations.  If you
vote against ratification for reasons that include
some of the issues I have discussed, then you may be
able to save some writing by citing this essay.

The second reason has to do with what happens after
the vote.  As I see it, there are three possible
outcomes:

    1.  The vote is negative, which would give the
        editors an opportunity to get it right.

    2.  The draft is ratified, and everyone pretends
        to live happily ever after.

    3.  The draft is ratified, and the unhappy folk
        design alternative syntactic layers, probably
        written up as SRFIs, that build upon the R6RS
        procedural layer.

This little essay of mine might be of some use, or
at least have some influence, in the event of outcomes
1 or 3.  I don't think outcome 2 is stable in the long
run.  I think it would evolve into outcome 3.

Thirdly, writing this essay gave me a chance to consider
whether I still believe what I wrote so long ago.

Conclusion
==========

Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear
necessary.

R6RS Scheme should demonstrate that a very small number
of rules for forming expressions, with no restrictions
on how they are composed, suffice to form a practical
and efficient programming language.

William D Clinger
5-9 July 2007

--------

[1] Jonathan Rees and William Clinger [editors].
Revised^3 report on the algorithmic language Scheme.
ACM SIGPLAN Notices 21(12), December 1986, pages 37-79.

[2] Michael Sperber et al.  Revised^5.97 report on the
algorithmic language Scheme -- standard libraries.
http://www.r6rs.org/versions/r5.97rs-lib.pdf
http://www.r6rs.org/document/lib-html-5.97/r6rs-lib.html

[3] Andre van Tonder.  Rationale issues.  Posted to
r6rs-discuss, 26 June 2007.
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002825.html

[4] William D Clinger.  Response to [3], 27 June 2007.
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-June/002889.html

[5] William D Clinger.  Record layers are not orthogonal.
Formal comment #90, 13 November 2006.
http://www.r6rs.org/formal-comments/comment-90.txt

[6] It doesn't matter whether the descriptor was created
using the syntactic or the procedural layer.  This is an
example of the interoperability we should have throughout
the record system.

[7] It is analogous to endianness, buffer-mode, et cetera.

[8] Whether the 5.97 draft allows a <record name> to be
exported from a library may not be entirely clear, but
disallowing such exports would be disastrous, so I assume
the 5.97 draft is meant to allow such exports.

[9] Andre van Tonder.  parent-rtd clauses in records.
Posted to r6rs-discuss, 3 July 2007.
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-July/003071.html