[R6RS] another glimpse into the abyss

William D Clinger will at ccs.neu.edu
Tue Mar 6 18:01:30 EST 2007


Kent wrote:

> Would you please restate this?  I'm having trouble reading this as
> anything other than self-contradictory.  Also, the first part (but not the
> second) seems to contradict statements you made in formal comment 198.

On 1 February, you wrote:

    A statically undecidable restriction would be a problem only if we were to
    *require* programs that violate the restrictions to be rejected prior to
    execution.  Simply *allowing* programs that violate the restriction to be
    rejected before execution would be sufficient to prevent people from
    considering such programs valid programs for which they can count on
    certain run-time behavior, i.e., exceptions being raised.

I pointed out that the 5.92 draft doesn't allow static
rejection for such reasons.  You said you knew that, so
I guessed that you were in favor of changing the draft to
allow it.  It seemed to me that allowing static rejection
would not be enough to discourage abuse of the exception
system unless compilers were allowed to reject programs
for fairly arbitrary potential violations.  I'm not a big
fan of that; I've been skeptical concerning some research
on semi-static typing and on verifying compilers because
it can lead to precisely that kind of arbitrariness, and
I've had some practical experience with a couple of overly
fussy Scheme compilers I'd rather not name.

Instead of waiting for you to propose what I feared might
be a grant of arbitrary discretion to compiler writers, I
wrote:

    Can we add that to the agenda?  Or does someone have
    to make a formal comment first?

You replied:

    We can certainly discuss this and any related issues amongst ourselves,
    but I think a formal comment may be a better way to proceed before we make
    any substantial changes so that we can get community input and not
    surprise the community with a change that might not be popular with some.

I took that to be a suggestion that I should file a
formal comment.  I couldn't very well file a formal
comment requesting the draft be changed to outlaw
something that was already illegal, so I proposed to
give compilers the least amount of discretion that
could conceivably have any beneficial effect toward
discouraging programmers from writing deliberate
violations in portable code.  It was something of a
preemptive strike; I was hoping to stir up enough
opposition to discourage you from proposing to grant
even more discretion to compiler writers.

The part of formal comment 198 that matters the most
to me is the proposal to add assertions.  I also favor
several things that came out during the discussion,
including: explicit definitions of what it means for
a program or implementation to conform to the report,
and allowing implementations to abort instead of
raising a &violation exception.  In my opinion, the
latter would be a much more effective way to discourage
programmers from writing a non-local transfer of control
as (car 0 0) than would your idea of allowing compilers
to reject such things at compile time.

OTOH, I certainly understand why compiler writers don't
like to have to generate executable code for programs
that contain obvious errors, and I tried to explain
that during the public discussion.  I should also admit
that arguments put forth during that public discussion
increased my sympathy for the idea that non-conforming
default modes are likely to be more useful than strict
conformance.  That's quite a change from my attitude of
three years ago, and it has come about in part because
of the general drift of the R6RS.

Will



More information about the R6RS mailing list