[R6RS] Safe/unsafe mode

[dyb at cs.indiana.edu]

> Apart from the two paragraphs that were flagged by
> FIXME comments

I found only one FIXME comment.

> the accuracy of safety.txt does not
> appear to be in dispute.

Yes, it is.  At least one claim not marked by FIXME is simply incorrect,
and others are at best misleading.  The main problem is that safety.txt
sets up an informal semantics for Proposal 3 that differs from the one I
offered, then uses that informal semantics to support a claim that
Proposal 3 is non-hygienic.  Yet, an analogous informal semantics can be
given for Proposals 1 and 2 to support exactly the same claim, and
safety.txt does not do so.  For the curious, here is the analogous
informal semantics for Proposal 2 (the one for Proposal 1 is left to the
reader):

    Proposal 2: Informal Semantics
    ==============================
    
    Implementations are allowed to provide a second, unsafe
    version of any subset of the core forms (forms defined by
    any standard library, plus call, where call is the form
    for a procedure call).  The names of unsafe core forms
    are distinguished from those of safe core forms by the use
    of some implementation-dependent technique for attaching
    invisible marks to the names of the core forms to indicate
    whether they are safe or unsafe.
    
    Within a script or library, an unsafe (safe 0) declaration
    means that, within the scope of the declaration, the
    names of the core forms that are in scope are rebound to
    the unsafe versions of those forms.  A safe declaration
    (safe 1, 2, or 3) means that, within the scope of the
    declaration, the names of the core forms that are
    in scope are rebound to the safe versions of those forms.
    
    Every procedure provides a second, unsafe entry point that
    may be used when the procedure is called from the unsafe
    version of call.  These unsafe entry points may be the
    same as or equivalent to the safe entry points, but are
    also allowed to be unsafe in various ways that might be
    expressed by implementation-specific means and/or unsafe
    (safe 0) declarations.
    
    An unsafe version of a form is allowed not to raise an
    exception for any situation that, in the words of the R6RS,
    must raise an exception.  For example, the unsafe version
    of lambda would not be required to raise an exception
    if one of the closures obtained by evaluating the lambda
    expression is passed an incorrect number of arguments.

Furthermore, safety.txt neglects to mention that, as Will has said,
Proposal 2 "runs afoul of one's intuition with respect to hygiene" for a
different reason (which is illustrated by the two examples I placed
near the bottom of safety2.txt).  Presumably Proposal 1 does as well.

safety.txt goes on to make a claim about Proposal 3's "failure of copy
propagation", yet as I've shown, there is no such failure.  In fact,
there is no failure even with the informal semantics safety.txt uses
for Proposal 3.  safety.txt also doesn't mention that there are similar
"failures" of other optimizations for Proposal 2.

The eqv? example in safety.txt is also wrong, but that's probably my
fault.  I once mentioned we could (but did not need to) allow eqv? to
return false in such cases with Proposal 3 without committing explicitly
one way or another.

> > In safety2.txt, I
> > have reworded the descriptions of Proposal 3 and the examples section to
> > describe the proposal in a way that I believe is more even-handed.
>
> That is one way of putting it.  "Fuzzier" might
> be a better way to say it, inasmuch as formalization
> of the formal semantics sketched in safety2.txt
> would probably involve the approach described in the
> corresponding section of safety.txt.

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. 
There was a typo (which I've since fixed): "Proposal 3" in the last
paragraph is now "Proposal 1".

> > Fortunately, safety.txt does not put the other proposals in a bad light,
> > so I was able to leave their descriptions alone for the most part, but I
> > did mention for them what (I understand) the macro expander must do with
> > declarations.
>
> I'm sure those additions were made with the best
> of intent, but they are factually incorrect, for
> reasons both obvious and subtle.  The draft of
> safety.txt alludes to one of the subtle reasons,
> albeit subtly, and flatly states one of the
> more obvious reasons.

Well, I wasn't sure, hence the parenthetical "I understand".  I was going
by the following in a March 5 note by Will:

  The way I would do that is to have the macro expander ignore
  declarations altogether, but pass them on to later phases of the
  compiler.

It's possible that Will has refined his model since then.

> > I have also added a couple of additional examples.
>
> Those are helpful.  I can't say as much for "illustrating
> that safety is a property of the source code in Proposal 3
> and of the expanded code in Proposal 2."  Surely no one is
> so foolish as to think source code means anything absent
> its semantics, and the semantics of source code differs in
> the two proposals, so I don't understand how anyone could
> fail to see that both safety and unsafety are properties
> of the source code and its semantics in both proposals.

Yes, that was poorly expressed.

The real point is that the Proposal 2 behavior for these will seem
unhygienic to some people.  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".  I can try to be more
precise if someone needs for me to be, but I believe the examples speak
for themselves.

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

> The difference is that, in Proposals 1
> and 2, it is the safe quality that is rebound at declaration
> points, not program identifiers as in Proposal 3.  I agree
> that this is an important difference.

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.  Also, with my informal semantics for Proposal 3, the safe quality
is rebound at declaration points, not program identifiers.  Thus, for all
three proposals, one can view it either way, so this cannot possibly
explain the difference.

Kent