[r6rs-discuss] [Formal] Allow compilers to reject obvious
r6rs at jdev.users.panix.com
Tue Feb 27 13:51:05 EST 2007
On Thu, Feb 22, 2007 at 09:06:02PM -0500, William D Clinger wrote:
> 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.
How arbitrarily bizarre? Section 4.3 assures us that, for "most of
the exceptional situations described in this report", the resulting
exceptions may be non-continuable. Thus, it is possible to place an
upper bound on the level of bizarreness by so doing.
Practically, an implementation can replace the immediately offending
expression with an appropriate application of the standard procedure
raise, which should be sufficiently tractable by whatever may come
after. And warn the user. Simple Matter Of Programming, as they say.
Should a compiler wish to be more fail-first-ful about this, the spec as
it is leaves a nonzero amount of latitude: for any procedure application
where a subexpression is known to not use its continuation (i.e.,
it will always raise an exception or call a captured continuation,
and no continuation will be captured and escape beforehand; e.g., an
application of raise), the implementation may decide to evaluate that
one first. The rest of the expression can then be removed as dead code
(or, if CPS, a useless argument); similar uselessness elimination will
take care of any pure expressions whose values are no longer needed. In
a sufficiently rabbity system, this should also take care of the rest of
the standard nondeterminism.
This even has some use beyond &violation -- because it's independent
of of the variety of non-returning, it would take care of user-raised
exceptions as well, and might even be useful in handling someone's
ornate macro-expanded non-exceptional control structure.
And maybe that's not enough. Maybe it's desired that the standard
should declare that, for any state from which further execution will
necessarily cause a non-continuable &violation to be raised, the
exception may be raised from that earlier state, even if this would
change the observable behavior of the program. That is, the raising of
a non-continuable &violation may be reordered before effects that should
precede it; it may also be lifted outside of a with-exception-handler or
One implication of such a rule is that debug-by-printf (pardon my
French) can no longer be relied upon; combining that with no way to
disable it and such deficient error messages as to make it a serious
problem should be considered a quality-of-implementation issue.
I myself have (at least at the moment) no personal interest in such
a provision, but it seems that others here may. I don't think any
equivalent rule has been proposed in this thread (though if I'm wrong
about that then I apologize for the noise); certainly several have been
posted which are not.
Or perhaps the example of C has made everyone stop caring what the
standard says, in which case this entire message may be ignored.
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))
More information about the r6rs-discuss