[R6RS] safe and unsafe; declarations

[William D Clinger]

Kent wrote:
> > I assume the answer is "yes" to all three questions,
> > but I want to make sure I'm not missing something
> > here.
>
> All of this is open to debate, of course, and if you have good arguments
> supporting this position, please advance them.

Okay.  As you know, but some of the other editors may
not, my Twobit compiler already implements an unsafe
mode.  As I explained earlier in this thread, Twobit
also provides fairly detailed control of several other
things that ought to be controlled, or at least
influenced, by the proposed declaration mechanism.  It
would be very easy to change Twobit so it pays attention
to the proposed declarations.  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.  I think most compiler writers would
want to implement a similar architecture.

Your proposal, when considered as a fictional account,
accurately describes the *behavior* of, but not the actual
*implementation*, described above up to the point at which
you introduce the identifier-priority procedure for use by
syntax-case macros.  In my view, the utility of that
procedure does not justify the hair involved in making my
macro expander pay attention to declarations.  Therefore,
in my system, the information you assume will be available
at macro expansion time will not in fact be available.  It
will most certainly not be available on a by-identifier
basis.  I think most compiler writers would want to
implement an architecture similar to mine.

With that as background, let's look at your answers.

> > Is it all right for an implementation to make the
> > identifier-priority procedure return 0 in all cases,
> > even if an implementation doesn't actually implement
> > an unsafe mode?
>
> If we're going to require implementations to be safe by default, then I
> prefer for the reported safe priority to be nonzero, at least in the
> absense of a declaration to the contrary.

So (identifier-priority 'safe #'k) would have to return
a positive number even if the actual priority is zero.

I think that's a bad idea, because some programmers
might interpret a positive priority for zero as giving
them permission to rely on the exception system for
safety instead of implementing their own checks.  It
would seem safer for identifier-priority to report
that the safe priority is 0 even when it isn't.

On the other hand, some programmers might interpret
a zero priority as giving them permission to call
unsafe code that they wouldn't be inclined to call
otherwise.  There does not seem to be any good way
for identifier-priority to return an arbitrary value
when it has no information.

> > Is it all right for an implementation to make the
> > identifier-priority procedure return 3 in all cases,
> > even when macro-expanding within the scope of an
> > unsafe declaration?
>
> I would say yes, if declarations are ignored.  In my opinion, however, the
> reported priority should be accurate in the sense that the implementation
> cannot itself treat an identifier in a manner that is inconsistent with
> the priority it reports for that identifier.

Yet it will be impossible for identifier-priority to
report accurate information unless macro expanders
are changed to keep track of declarations on a
per-identifier basis.

> While it might be possible
> to detect violations of this proposed rule for each of the modes, the most
> obvious is a safety violation.  In particular, if identifier-priority
> reports a nonzero safe priority for an identifier naming a standard
> procedure, a reference to that identifier should not evaluate to an unsafe
> version of the standard procedure.

That implies that, in a system that provides unsafe mode
without keeping track of declarations at macro expansion
time, the identifier-priority procedure should always
return 0, just in case there was an unsafe declaration
somewhere.  That is at odds with your previous answer
that identifier-priority should report a nonzero priority
for safe when it doesn't have enough information to be
accurate.

> > Is it all right for an implementation to make the
> > identifier-priority procedure return a pseudo-random
> > integer in the range [0,3], no matter what declarations
> > the compiler is recognizing?
>
> I prefer not, as my answers to your first two questions above indicate.
> Also, if we say that an implementation returns "the implementation
> default" priority for a mode when declarations of that mode are ignored,
> then returning a pseudo random priority when declarations are ignored
> would be inappropriate.

The problem is that the macro expander is likely to ignore
declarations, but the compiler is likely to pay attention
to them.  The identifier-priority procedure would have to
return *something*.  Are you saying it should return 2, if
that happens to be the default priority, even though the
compiler will respond to a (safe 0) declaration by treating
the priority as 0?

Let me summarize.  In a system whose macro expander just
passes declarations on to the compiler, which is the way
most implementations are likely to work, identifier-priority
will have to return some arbitrary value.  Your answers to
my three questions imply that arbitrary value should be:

1.  nonzero;
2.  zero;
3.  the default.

Will