[R6RS] Safe/unsafe mode

[William D Clinger]

For some badly needed perspective on the ongoing
discussion of safe/unsafe, I am going to review
our discussions of this issue before I respond
to Kent's latest complaints.

In the first conference call for which I have notes,
on 9 February 2006, I gave a brief status report on
arithmetic, saying that the semantics of safe and
unsafe mode is an issue for all of R6RS, not just
arithmetic.  On 14 February, Mike volunteered the
two of us as sub-editors for safe mode.  He posted
an email he had sent to me privately, and I posted
my private response.  The gist of that exchange was
that, while allowing an unsafe mode, we need to nail
down the semantics of safe mode.  Mike also stated
his belief that, when an anomalous situation is
encountered in safe mode, implementations should be
required to raise an exception.

On 26 February, I posted the first draft of what is
now draft/safety/safety.txt.  On 28 February, Kent
asked whether declarations would be hygienic "in the
sense that a declaration introduced by a macro affects
only the code introduced by that macro".  I thought
Kent was asking whether variable references would be
hygienic, because there was no pre-existing or obvious
definition of what hygiene might mean for declarations.

On 3 March, I stated my own interpretation of unsafe
mode:

    Anything whatsoever is allowed to do anything
    whatsoever once unsafe code has created a situation
    in which the R6RS would allow the implementation to
    raise an exception."

My concept was and is that the semantics of unsafe mode
are relatively unimportant, so long as we have a clear,
easily understood demarcation of the boundary between
safe and unsafe code.

Kent, however, argued for a complex boundary, claiming
he had a more precise definition for the scope of a
declaration, and that his definition would "bring the
scoping rules for declarations in line with lexical
scoping and referential transparency".

Imagine my amusement when I figured out that Kent's
allegedly referentially transparent scope rule amounts
to non-hygienic rebinding of program identifiers at
declaration points.  Kent has come up with all sorts of
other ways to explain his semantics, but none of them
differ in any observable respect from the implicit,
non-hygienic rebinding of identifiers at declaration
points, and this explanation of his semantics will be
more easily understood by most programmers than Kent's
alternative explanations.

In his most recent messages, Kent no longer seems to
be arguing that his semantics is more hygienic than
others, but is now arguing that other proposals are
non-hygienic in much the same way.  I agree that
Proposals 1 and 2 are non-hygienic in *somewhat* the
same way, but I see an important difference between
non-hygienic rebinding of a safe quality (which cannot
be named in expressions) and non-hygienic rebinding of
identifiers (which *are* the names in expressions).

Kent denies the importance of that difference, on the
grounds that all three proposals *could* be implemented
via the same mechanism, which Kent appears to prefer
because he can try to hide the non-hygienic binding in
his examples.  If Kent were to give a more precise
formal semantics, however, the substitutions of his
examples would have to be guided by precise rules that
explain which identifiers are bound to which values in
which scopes, and the fact that those rules would
constitute implicit, non-hygienic binding would become
very plain.

The same would be true for Proposals 1 and 2, if their
formal semantics were expressed using Kent's preferred
mechanism.  Even if they were, far fewer identifiers
would be subject to non-hygienic rebinding.  (Yes, I
could prove that.)  Furthermore I have already sketched
a formal semantics for Proposals 1 and 2 that does not
involve implicit, non-hygienic rebinding of *any*
identifiers.

By contrast, no one has yet sketched a formal semantics
for Proposal 3 that avoids implicit, non-hygienic
rebinding.  I am not saying it cannot be done.  All I
am saying is that no one has done it.  Kent, of course,
denies this:

    The formalization may be less precise in the sense
    that it omits some misleading details, but it is
    more accurate, and it already does involve the
    approach described in the corresponding section of
    safety.txt.

My answer to that is that the "misleading details" that
Kent omitted in his semantics are essential to the
formalization he thinks he has sketched.  Without them,
his semantics does not explain which identifiers are
bound to which values in which scopes.  Without that
information, it is impossible to reproduce his examples.

Regarding a couple of examples, Kent wrote:

> The real point is that the Proposal 2 behavior for
> these will seem unhygienic to some people....

That, of course, is an empirical question.  Were this a
more open process, we could collect some actual data.

> ....Perhaps it would be more accurate to say that
> Proposal 2 violates referential transparency in a
> sense similar to the use of the term in "Macros that
> work"....

Proposal 2 does not violate referential transparency in
the sense in which that term was used in "Macros That
Work", because that paper applies the term only to
program identifiers.  I have sketched a formal semantics
in which *no* identifiers are subject to *any* implicit,
non-hygienic rebinding.  That Kent would prefer to explain
the semantics of Proposal 2 using the kind of non-hygienic
semantics he is pretty much forced to use for Proposal 3
may say something about Kent, but it says nothing about
Proposal 2.

> > Here is my best guess as to what you were trying to say:
> > I think you were trying to say that Proposals 1 and 2 both
> > involve something analogous to the implicit non-hygiene that
> > pervades Proposal 3.
> 
> No.  It is a much more obvious breakdown in hygiene than the one you have
> found with your particular take on the informal semantics of Proposal 3
> and which exists as well with the analogous informal semantics of
> Proposals 1 and 2.

Kent has invented a novel meaning for the word "hygiene",
and is using it for the pejorative purpose of attacking
proposals that are provably hygienic with respect to the
traditional meaning of that term.

> This doesn't explain anything, since the "implicit non-hygiene that
> pervades Proposal 3" also pervades Proposal 2, using the analogous
> informal semantics, with program identifiers rebound at declaration
> points.

Once again, Kent must insist upon using his own style of
semantics, for his pejorative claims would be ludicrous
under the formal semantics I have sketched for Proposal 2.

> Also, with my informal semantics for Proposal 3, the safe quality
> is rebound at declaration points, not program identifiers.

Kent's informal semantics glosses over the transformation
from unadorned identifiers to marked identifiers.  Were he
to make that transformation precise, the non-hygienic nature
of Proposal 3 would become plain for all to see.  (Actually,
I can see a couple of alternative ways to do it, but they
would be so much fun to ridicule that I won't explain them
until Kent actually espouses them.  Bwahhahahahah!)

> Thus, for all
> three proposals, one can view it either way, so this cannot possibly
> explain the difference.

Kent is reduced to espousing the above fallacy.  The fact
that one *can* regard all three proposals as non-hygienic
does not trump the fact that two of the three proposals can
easily be given a hygienic formal semantics, while the third
cannot.

Besides, as I noted earlier, Proposals 1 and 2 would be less
non-hygienic than Proposal 3 even if we were so foolish as
to use Kent's preferred style of semantics for all three.

Will