[erlang-questions] Simple multi-case

[Raimo Niskanen]

I'll try to elaborate on why multi-case is not a part or the
Erlang language (yet).

The general syntax would have to allow something like:

case foo(Bar) of
    {ok,Result} | {error,{notfound,Reason}} ->
        %% Result and Reason can not both be bound here.
        {ok,Result,Reason}; %% Unsafe variable compile error!
    {error,einval=Reason} = Error ->
        Error;
    {error,Reason} ->
        {error,Reason}
end,
{done,Reason} %% Is Reason bound here? No - unsafe too.

So, there would have to be a rule that any variable used
in a multi-case-clause body would have to be bound in
all multi-case-patterns (or of course before the case),
which would be another rule as clumsy as the not to 
well known that if a variable is bound in all case
clauses or case bodies it is bound after the case.

It would be awkward at least for the compiler writer,
and just as ugly as the export-from case rule that
(many argue) should be removed but can not be.
        
On Mon, Nov 13, 2006 at 05:41:37AM +0000, datacompboy wrote:
> 
> >> Since there more than one call, but too small code to move it
> >> into separate fun.
> 
> > There is no such thing as code that is too small to move into a separate function.
> 
> separate function -- more chars to type, and code far from table itself.
> separate function is not a problem to speed of runtime, but that problem for development speed.  I need at least create new function name, that must contain info about "what doing here", but not "how it doing that", since after some changes name will be wrong...
> 
> Cascade CASEs better, than just copy code, and better than separate function for short results. As for now, its my decision:)
> 
> But may be in future, parse transform. But far, future....
> --
> --- suicide proc near\n call death\n suicide endp
> _________________________________________________________
> Post sent from http://www.trapexit.org
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB