Kent wrote:
> I'm not sure it's a change, is it? Is R6RS actually clear on this point?
I was referring to a change from R5RS, which
is most definitely not very clear on whether
((lambda (x) E[x]) '<datum>)
is equivalent to
E['<datum>]
That lack of clarity was probably an accident, but
that lack of clarity at least makes it possible for
programmers, implementors, and semanticists to
sustain a plausible illusion that this special
case of the beta rule holds for Scheme. At the
very least, it permits implementations in which
that special case of the beta rule does indeed
hold.
You are proposing to forbid implementations in
which that special case of the beta rule holds.
That would most definitely be a change from the
R5RS.
It is probably a change from the current draft of
the R6RS as well; were it not, it would mean the
current draft of the R6RS contains a subtle change
in the core semantics that has not been approved
by the editors. (That is entirely possible, since
there have been several other examples of that,
mostly by accident.)
> I don't think that's true. Transformations that programmers perform on
> their own code are never bound by the semantics of the language.
That's a rather cynical view. It seems to me that
one of the primary purposes of a semantics is to
allow programmers to reason about transformations,
even if many programmers still prefer to operate
by modify-and-pray.
> My suggestion would inhibit compilers from making certain transformations
> or require them to be more careful in doing so.
I don't understand how forbidding both compilers
and programmers to rely on an important special
case of the beta rule is going to help anyone.
I agree that the R5RS semantics does not allow
programmers to rely on this special case of the
beta rule in portable code. I was hoping we
could repair that in a way that endorses this
special case of the beta rule, not by forbidding
it to hold.
Will