[eeps] Request for comments on EEP-25 "Unnesting cases"
Mon Dec 22 03:39:47 CET 2008
On 21 Dec 2008, at 5:10 am, Geoff Cant wrote:
> I like the general idea, but am not so sure about leaving out the
> we're falling through.
> case voltage() of
> high -> panic()
> ; normal -> continue_operations()
> ; or case status() of
> ; emergency > set_speed_slow()
> ; normal -> shut_device_down()
> We miss the fact that the second case statement is tried when the
> voltatge() is low. I can see myself 'improving' voltage() to return a
> fourth value and forgetting to update this case statement.
Remember what this is really for! It's so that the people
who _really_ want to write
if e1 then b1
elif e2 then b2
elif e3 then b3
case e1 of true -> b1
; case e2 of true -> b2
; case e3 of true -> b3
; _ -> b4
"Leaving out [all] the value[s] we're falling through" is
very important for this use.
Don't forget that an Erlang programmer can ALREADY write
of high -> panic()
; normal -> continue_operations()
; _ -> case status()
of emergency -> set_speed_slow()
; normal -> shut_device_down()
If we do not force people to spell out all the possible
values in a case *now*, why turn around and force them
to do so in a variant of the notation which is explicitly
an "anything else" handler?
> Perhaps there's some way to specify the value to match?
No, because who says that there is ONE value, or that it
can be specified by a pattern without any guard? Indeed,
when I wrote that example, I had multiple other values in
mind for both functions, and simplified it.
If I can write "; _ -> case STUFF end", what's so bad about
writing "; or case STUFF"? If you try to force people to
write a value in there, what stops them writing "_"?
> I like that this EEP reduces the need for hard to read nested case
> statements, but I don't like that in its current form the EEP requires
> me to give up explicit case clauses in order to use it.
Aren't you sick and tired of demands that Erlang's 'if' should
be more like Fortran's IF or Lisp's COND? I am. That's what
this is all about. Leaving the other cases implicit is part
of what it's *for*.
Perhaps before considering EEP 25 there needs to be some consideration
of a possible 'else' keyword. I'm thinking about the difference
between Common Lisp and Scheme here. In Common Lisp, you have
where "T" is any expression that evalutes to true, and T happens to be
a constant that acts as truth in Common Lisp. Scheme allows
where "else" is a keyword, also used in CASE. In Erlang, if you want
an 'if' to have an else part, you write '; true ->'. If you want a
'case' to have an else part, you write '; _ ->'. How very like Common
Lisp! It wouldn't kill us to write both of those as 'else'.
Such a change would "leav[e] out the value[s] we're
falling through", but '; -> true' and '; _ ->' are ALREADY legal
Erlang, so I think the only real change would be clearer code.
Not that I'm going to write an EEP for it (:-).
More information about the eeps