On 08/08/2011 12:31 PM, John Cowan wrote:
> Per Bothner scripsit:

>> More fundamentally, the paradigm seems very awkward.  The classic
>> exception-handling idiom in a language with non-continuable exception
>> seems to require call-cc, which is rather painful:
>
> See "guard" (4.2.7).  This unwinds the dynamic state while executing the
> appropriate catch clause and then falls out the bottom of the guard.  But
> if no catch clause applies, the state is rewound (except for the current
> handler) and the next handler is tried.

Yes, that seems friendlier.

Assuming guard is definable in terms of with-exception-handler,
there should be a definition in section 7.3 "Derived expression types".

In general, the division of the report into separate chapters
for Expressions, Program structure, and Standard procedures, is quite
unnatural.
For example, it would be better to put guard and with-exception-handler
in the same section.

The distinction between "Primitive expression types" and "Derived expression
types" is also unnatural.  Why is "if" in the former while "cond" is in
latter?
Maybe my implementation has cond primitive and if implemented in terms
of cond?
We already dropped the distinction between primitive syntax and derived
syntax;
we should follow that logic in re-organizing the specification.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports