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

From: William D Clinger <will>
Date: Thu Oct 26 16:45:59 2006

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

Abdulaziz Ghuloum quoting me:
> > The meaning of the word "correct" will be defined in part
> > by the R6RS. ^^^^^^^ ^^^^^^^
>
> It's not in the current draft, right?

Wrong. The current draft contains the language I quoted,
from which I concluded that any program that imports cons
from (r6rs base) or (r6rs) and calls that cons with three
arguments is incorrect.

> And does the "in part" part mean
> that implementors will have some freedom in rejecting/accepting
> programs as they please?

No, that is not what I meant by "in part", but it is true
that implementors will have some freedom to decide which
programs they will reject or accept.

In my view, one of the biggest problems with the draft
R6RS is that it almost tries to give the impression that
implementations are required to reject all incorrect
programs. In my view, the R6RS should draw a clear
distinction between correct programs (which it is the
responsibility of programmers to write) and programs
that implementations are required to reject (which is
obviously the responsibility of implementors of the
language).

This is a pervasive problem with the draft R6RS. That
is why it is coming up again and again in discussions
of many different issues.

> If (lambda () (cons 1 2 3)) cannot possibly be correct, then what about:
> (lambda () ((begin cons) 1 2 3)),
> (lambda () ((if #t cons list) 1 2 3)), and
> (lambda () ((f) 1 2 3)) where f may/will return cons?

On my reading of the draft R6RS, the first three cannot
possibly be correct, and might be rejected at compile
time. The last might be correct, and will not be rejected
at compile time (unless the compiler has more information
available to it than you have told us).

Will
Received on Thu Oct 26 2006 - 16:45:55 UTC