[r6rs-discuss] Compile-time detection of contract violations

From: William D Clinger <will>
Date: Thu Oct 26 10:23:50 2006

I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors.

Jason Orendorff wrote:
> What about at compile time? Does R5.91RS allow an implementation to
> detect a contract violation at compile time and reject the program? I
> couldn't find any such wording. I think this should be allowed.

It is, I think. Section 9.22 of the R5.91RS draft says:

    Most implementations are able to recognize some violations
    when parsing, expanding macros, or compiling a definition
    or expression whose evaluation has not yet commenced in
    the usual sense. Implementations are allowed to use
    nonstandard exception handlers at those times, and are
    encouraged to raise &syntax exceptions for violations
    detected at those times, even if the definition or
    expression that contains the violation will never be
    executed. Implementations are also allowed to raise
    a &warning exception at those times if they determine
    that some subexpression would inevitably raise some
    kind of &violation exception were it ever to be
    evaluated.

>From this it is clear that implementations are allowed to
raise a &warning exception at compile time for things like
(lambda () (cons 1 2 3)), if cons is imported from either
the (r6rs base) or (r6rs) libraries. It is also explicit
that implementations may use nonstandard exception handlers
at compile time.

It seems to me that a nonstandard exception handler might
handle the &warning exception by rejecting the entire program.

Abdulaziz Ghuloum wrote:
> An implementation can issue warnings for such cases, and many do so
> already. If implementation are allowed to refuse to compile these
> programs, the situation changes. I might be developing a library under
> one R6RS-conforming implementation which does not perform any analysis
> w.r.t. calling procedures with incorrect number of arguments. Suppose
> also that my library is correct and never actually makes erroneous
> calls at runtime (say I have a proof of that). If I distribute my
> library, it might be rejected by another, also R6RS-conforming,
> implementation that happened to decide that an erroneous call *may*
> occur.

As explained above, I believe that rejection is a very real
possibility.

> My position is that if I write a correct library for R6RS, I want it to
> be accepted by *all* R6RS-conforming implementations, regardless of how
> extensive and incomplete its analysis may be.

The meaning of the word "correct" will be defined in part
by the R6RS. On my reading of the current draft, a program
that contains (lambda () (cons 1 2 3)) cannot possibly be
correct, even if you have a proof that the call to cons
will never be executed.

(I am assuming that cons is imported from (r6rs base) or
(r6rs), and that the call to cons occurs within the scope
of that import and has not been shadowed by any local binding
of cons.)

Will
Received on Thu Oct 26 2006 - 10:23:42 UTC