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 dynamic-wind. 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))))) _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
