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

From: Abdulaziz Ghuloum <aghuloum>
Date: Tue Oct 24 11:10:25 2006

On Oct 24, 2006, at 10:20 AM, Jason Orendorff wrote:

> Many places in R5.91RS specify &contract exceptions to be raised for
> various errors. For example, (cons 1 2 3) causes a &contract
> exception (too many arguments).

Yes. It causes a runtime exception.

> In R5RS, the spec just said "it is an error". Implementations were
> allowed to detect this at compile time, at run time, or not at all.

I don't think so. In R5RS, it is an error to call a procedure with
more/less arguments than it expects. The compiler, with the presence
of global assignment, could not, in general, assume that any reference
to cons is actually Scheme's cons that takes 2 arguments. Plus,
(define (f) (cons 1 2 3)) is ok as long as no one calls f.

> R5.91RS rejects the "not at all" option, except under (declare
> unsafe). So far, so good.
>
> 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.

So, which contract is violated when you evaluate (lambda () (cons)) ?

> Opinions will differ on whether this behavior is helpful, and no
> compiler can detect all contract violations at compile time.

Of course not.

> Still,
> any optimizing compiler will be able to detect some of these, and
> treating them as errors seems reasonable to me.

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.

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.

Aziz,,,
Received on Tue Oct 24 2006 - 11:10:15 UTC