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

[Anton van Straaten]

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