[eeps] Request for comments on EEP-25 "Unnesting cases"

[Andras Georgy Bekes]

Hi all,

I support the EEP, although I don't really like the new syntax (as most 
of us).

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 
construct.

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 
away."

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
after A
end

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
after A
end

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."

Opinions?

	Georgy