I'm sure you realized that this proposal would lead to a horrendously
long debate. I'll try to restrain myself, however.
My concern is that allowing implementations to `reject' a program
that would inevitably raise an error `were it ever to be executed'
might make it more difficult to write macros. One can imagine
a macro that expanded into a large conditional clause which
contained `dead code' that `would inevitably raise a &violation
exception were it ever to be executed', but the user has
constructed the condition such that the code would never be
executed (although the compiler may not be able to prove so).
I agree that it is undesirable to allow arbitrarily perverse code
*designed* to throw &violations, but I don't see how the
compiler can tell the difference between deliberate attempts
and accidental attempts.
Oh, and what do you mean by `reject'?
On 2/22/07, William D Clinger <will_at_ccs.neu.edu> wrote:
> ---
> This message is a formal comment which was submitted to formal-comment_at_r6rs.org, following the requirements described at: http://www.r6rs.org/process.html
> ---
> Submitter: William D Clinger
> Email address: will_at_ccs.neu.edu
> Issue type: Enhancement
> Priority: Major
> Component: Concepts
> Report version: 5.92
> Summary: Allow compilers to reject obvious violations.
>
> The current draft legitimizes many situations that,
> according to the R5RS, are clear errors. The draft
> generally does this by requiring all implementations
> to raise a &violation exception when the situation
> arises. That allows portable programs to implement
> an arbitrarily bizarre semantics for the violation
> via inappropriate exception handlers.
>
> Unless we expect programmers to abuse the exception
> system on a routine basis, however, the cause of a
> &violation exception is far more likely to be a
> mistake than a deliberate misuse of the exception
> system.
>
> Several extant Scheme compilers already perform static
> analyses that can occasionally establish that some
> expression would inevitably raise a &violation exception
> were the expression ever to be executed. The R6RS
> library system will make it much easier for compilers
> to detect such violations at compile time.
>
> The current draft of the R6RS effectively forbids
> static rejection of libraries and programs that
> contain such violations, because there is always
> the remote possiblity that the violation might be
> a deliberate ploy to invoke some exception handler
> that might be installed by some other library.
>
> That seems unfortunate, especially when compared
> to the draft's absolute requirements that programs
> containing &lexical or &syntax violations always be
> rejected prior to execution.
>
> I recommend that language such as the following be
> added to the report:
>
> Implementations may reject a library or program
> prior to execution if they can establish that
> (1) some definition or expression within the
> library or program would inevitably raise a
> &violation exception were it ever to be executed,
> and (2) the exception would be raised without
> calling any of the following procedures: error,
> assertion-violation, raise, raise-continuable.
>
> I also recommend that an assert syntax be added to
> the above list and to the R6RS, with syntax akin to
>
> (assert <expression>)
>
> and implementation-dependent semantics akin to
>
> (if (not <expression>)
> (assertion-violation #f "Assertion failed"))
>
> but with the expectation that many systems will
> provide better error messages, localization, and
> optimization than would be obtained with the above
> macro expansion.
>
> Will
>
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
--
~jrm
Received on Sun Feb 25 2007 - 00:06:24 UTC