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

From: Anton van Straaten <anton>
Date: Mon Feb 26 14:39:58 2007

Marcin 'Qrczak' Kowalczyk wrote:
> In other words, an implementation is not allowed to reject a program
> only on the basis of a sophisticated, non-standard analysis which would
> conclude that a certain fragment will signal a violation at runtime.
> In other words, program rejection criteria should be deterministic and
> implementation-independent.
>
> This is to prevent the following bad scenario:
> - Programmer A creates a program.
> - The program is tested on a Scheme implementation, and everything
> is fine.
> - A few years later, a few countries away user B compiles the program.
> - She uses a different Scheme implementation, which is smarter, and
> thanks to flow analysis coupled with a soft type system it finds
> a genuine bug in the program. The bug is hidden in a path of code
> which is executed only in pathological cases, e.g. during I/O error
> recovery, and that's why it has never been found during testing.
> - The bug prevents user B from using the program at all, even if it
> would never execute the problematic code. She is not qualified to
> understand and fix bugs in a large program she has not written.

Why wouldn't this simply be a quality of implementation issue? User B
should complain to the authors of the "smarter" Scheme implementation,
who in the most likely scenario, would point out to her that there's a
compiler option to relax checking. I don't see that attempting to guard
against situations like this is a necessary or even important function
of R6RS.

Anton
Received on Mon Feb 26 2007 - 14:39:19 UTC