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

[Felix Klock]

On Nov 1, 2006, at 3:23 AM, Michael Sperber wrote:

>
> Felix Klock <pfr6rs at pnkfx.org> writes:
>
>> Are we talking about:
>> 1.) The encouragement of implementations to raise &syntax exceptions
>> when encountering subexpressions with violations
>> 2.) The permission of implementations to raise &warning exceptions
>> when encountering subexpressions with "inevitable" violations
>
> 1., to my mind, is bogus: We should require an exception with
> condition type &syntax to be raised upon a syntax violation, and
> prohibit an exception with condition type &syntax to be raised in
> other circumstances.

Okay.  This makes sense to me.

> 2. is OK, but the relevant issue is not with raising the exception,
> but rather with handling it.  There are probably two separate strands
> here: Expansion by `eval', and expansion through compiling/running a
> script and importing a library.  They have in common that exceptions
> with serious condition types should prevent the expression or program
> from being run, and that they should proceed upon all others.  I think
> we should permit the default handler in place when expanding through
> compiling/running a script and importing a library to print out a
> message when encountering an exception with condition type &warning,
> before proceeding.

Both issues (raising and handling) are relevant.  We can't reason  
about which handler is relevant to the discussion without knowing at  
what point(s) the exception could be raised.

But from what you have written here, I think I understand your  
position better.  See below.

>> Thus, to clarify my understanding of Mike's position, I ask whether
>> code like the following is specified as returning 1, 2, either,  
>> or ...?
>>
>> (call-with-current-continuation
>>   (lambda (exit)
>>     (with-exception-handler (lambda (x) (exit 2))
>>       (with-exception-handler (lambda (x) (exit 1))
>>           (lambda () (cons 1 2 3))))))))
>>
>> That is, a JIT compiler might wait until it was evaluating the
>> innermost (with-exception-handler ...) to actually raise a &warning
>> about the (cons 1 2 3).  Such systems might then return 2 as their
>> result, right?
>
> No.  The &warning needs to be ignored.  1 should be returned always.

So, should 9.22 be revised to say that &warning can only be raised  
during expansion of a whole expression, and not during the evaluation  
of a subexpression?  (The current text of 9.22 lists parsing,  
expansion, and compilation as times when such violations could be  
detected; it is not clear to me whether this use of the term  
"compilation" could include JIT compilation during the actual  
evaluation of the expression, which is why I brought JITs up above.)

-Felix