Abdulaziz Ghuloum <aghuloum_at_cs.indiana.edu> writes:
> The syntax is constructed on the assumption that conditional
> dispatch on the condition type is the default action that would be
> performed in the guard handler. This is not necessarily the case.
It is not necessarily the case, but it is a very common one. Witness
the exception-handling mechanisms in languages like ML, Java, or C++,
which all perform dispatch. (Or even in the ancient Indiana proposal,
on which probably somebody at your site can provide information.)
> Examples from the draft:
>
> (guard (condition
> (else
> (display "condition: ")
> (write condition)
> (newline)
> 'exception))
> (+ 1 (raise 'an-error)))
These examples are hardly representative, as they are taken verbatim
from SRFI 34, which did not assume a matching condition system.
Moreover, they are meant to illustrate the various cases distinguished
by the semantics rather than present common use cases. Having said
that, I agree better examples would be nice.
> Suggestion: Many ideas are plausible. One possibility is to
> specify the syntax of guard expressions as:
>
> (guard <variable> <handler-expression> <body-expression>)
I'm sympathetic to making any dispatch explicit, but note the
semantics of `guard' in the case where no clause matches. One way to
do this would be to bind another variable to a procedure the handler
code can call to punt.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Sun Nov 19 2006 - 05:44:24 UTC