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

From: Felix Klock <pfr6rs>
Date: Wed Nov 1 03:35:15 2006

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
Received on Wed Nov 01 2006 - 03:34:43 UTC