[r6rs-discuss] [Formal] Allow compilers to reject obvious violations

From: William D Clinger <will>
Date: Sun Feb 25 11:20:04 2007

Mike Sperber asked:
> Why is it not enough for the compiler to just issue a warning, and to
> then abort at run time? (Scheme 48 also does some degree of arity
> checking at compile time, and offers a special mode to make warnings
> abort the compiler.)

According to the current draft R6RS, implementations
are not allowed to "abort at run time"; they would
have to raise a &violation exception, from which the
program might conceivably recover in a portable way.

By legitimizing violations in that way, the draft
R6RS requires compilers to generate R6RS-compatible
code (whatever that means; see below) for programs
that violate the requirements of the draft. That
means compilers must be written in such a way as
to continue to operate correctly when even the most
basic requirements of the R6RS are not met by the
program being compiled.

That means compiler writers will have to write extra
code for the sole purpose of undoing optimizations
whose correctness temporarily assumes the program
being compiled contains no fundamental violations
of a kind that is easily detected after the program
has been transformed according to the optimization,
and is not so easily detected before the program
transformation. Requiring compiler writers to write
this extra code, instead of allowing them to reject
programs that violate the basic requirements of the
language, is a silly waste of implementors' time.

For some compiler writers, the most likely response
to a standard of silliness approaching that of the
current draft is to ignore the sillier parts of the
standard in their compilers, and to provide strict
R6RS conformance (whatever that means; see below)
only in their interpreters. If at all.

Which brings us to the question of what it would
mean for a program or implementation to conform
to the R6RS. The current draft doesn't say much
about that, and what it does say is confusing:

  * Portable programs are allowed to violate many
    absolute requirements.

  * Implementations must execute programs that
    violate those absolute requirements, treating
    them as perfectly valid programs.

  * Implementations must provide safety guarantees
    that cannot possibly be implemented for programs
    that interoperate with certain industry-standard
    libraries, thereby giving the impression that
    the R6RS is intended to describe a toy language.

Et cetera. I could go on, but there is little point
to enumerating the same problems I have mentioned so
many times before.

I think the R6RS should define what it would mean
for programs and implementations to be:

  * R6RS-conforming programs
        (do not violate any absolute requirements)
  * R6RS-portable programs
        (may violate absolute requirements, but
        all R6RS-conforming implementations must
        still execute them)
  * R6RS-compatible programs
        (may contain or link to source code or
        libraries not written in R6RS Scheme)
  * R6RS-conforming implementations
        (execute all R6RS-portable programs in a
        manner consistent with the absolute
        requirements of the R6RS, but may violate
        some absolute requirements when executing
        R6RS-compatible programs, if they deign to
        execute such programs at all)
  * R6RS-compatible implementations
        (execute all R6RS-conforming programs in
        a manner consistent with the absolute
        requirements of the R6RS, but may violate
        some absolute requirements when executing
        R6RS-portable or R6RS-compatible programs)

Recognition of R6RS-compatible implementations might
go a long way toward convincing some compiler writers
that the R6RS language is worth implementing. Most
of those who would insist upon an R6RS-conforming
implementation would be happy using an interpreter.
A classification such as the above might therefore
make it possible for more Schemers to achieve greater
happiness.

Will
Received on Sun Feb 25 2007 - 11:19:53 UTC