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

[Richard O'Keefe]

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  
> value
> we're falling through.
>
> case voltage() of
>    high -> panic()
>  ; normal -> continue_operations()
> ; or case status() of
>  ; emergency > set_speed_slow()
>  ; normal -> shut_device_down()
> end
>
> 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
	else b4
	end
can write
	case   e1 of true -> b1
	; case e2 of true -> b2
	; case e3 of true -> b3
	;            _    -> b4
	end

"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
     case voltage()
       of high -> panic()
        ; normal -> continue_operations()
        ; _ -> case status()
                 of emergency -> set_speed_slow()
                  ; normal -> shut_device_down()
               end
     end

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
	(cond
	  (test-1 body-1...)
	  (test-2 body-2...)
	  ...
	  (T      body-n...))
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
	(cond
	  (test-1 body-1...)
	  (test-2 body-2...)
	  ...
	  (else   body-n...))
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 (:-).