[eeps] Request for comments on EEP-25 "Unnesting cases"
Andras Georgy Bekes
Wed Jan 7 15:53:47 CET 2009
I support the EEP, although I don't really like the new syntax (as most
On the other hand, I feel it'd be better to generalize the case
construct even further. The EEP introduces a more general form of case,
but we already have a better-than-case construct, the try-catch
First, the try-catch construct should be relaxed a bit. Currently,
"The of, catch and after sections are all optional, as long as there is
at least a catch or an after section". This limitation could be
removed. A try expression with no catch section and no after section
(example: try Expr of P1 -> B1; P2 -> B2 end) should be allowed and
should do the same as what a case expression would do. This flexible
try construct could obsolate the case expression.
Second, the ideas of EEP-25 should be applied to the try construct,
obsolating the if expression as well. "Perfection is achieved, not when
there is nothing left to add, but when there is nothing left to take
A case-equivalent try expression (i.e. a try-catch with no catch section
and no after section) can be easily extended according to the proposal,
but what to do with "real" try-catch expressions?
Let's see a simple one, with only one catch or after section.
try C1 of P1 -> B1
; or try C2 of P2 -> B2
catch X -> Y
If I were the reader of this code, I'd think that exceptions are caught
in both C1 and C2. However, if we extract the nested try expression,
(i.e. following the logic of the proposal), the above means:
try C1 of true -> B1
; _ -> try C2 of true -> B2 end
catch X -> Y
I.e. exceptions are caught only in C1. Here I'm stuck. I think catching
the exceptions in both C1 and C2 is the intuitive behaviour. But the
implementation of that would probably be more difficult than "It will
be entirely in the parser."
More information about the eeps