[erlang-questions] style question - best way to test multiple non-guard conditions sequentially

[Richard A. O'Keefe]

On 21/06/2013, at 3:29 AM, Jonathan Leivent wrote:

>        ?ELSE
>            expr0,
>            expra,
>            ?BREAK(exprb),
>        ?ENDIF.

The ?BREAK is rather horrible; to my mind, far more horrible than nice
clean obvious closures.

I wrote:
> 
>> 
>> However, I cannot help feeling that in each specific instance
>> of this there would be something better to write instead.  So
>> how about showing us a real example?
> 
> Anything that would have worked in an if statement were the conditions just guards.  In the case I'm interested in, the conditions are predicates on an opaque type - so they can't be guards.

That's interesting, but I doubt that anyone ever thought
you _could_ have written your code as a simple 'if'.
*How about showing us a real example?*
As in, actual code.

Real examples often show opportunities for restructuring in
completely different ways.

Also, I'm having a hard time imagining so many sequentially
tested conditions that

	case C1
	  of true -> A1
           ; false ->
	     case C2
               of true -> A2
                ; false ->
		   ...
             end
	end

is really hard to write.  It's certainly what
cond C1 -> A1 ; C2 -> C2 ; ... end
would compile into, if it existed.


>> Because back when Erlang was invented, there were no conditions that
>> were not guard tests *only*.  For example, X > Y was not an expression.
>> There were no andalso or orelse.
> 
> OK - I will then add a word to the above question: why does Erlang *still* require the conditions in an if statement to be guards?
> 
> How hard is it to remove this restriction?

Expressions and guards have radically different semantics.
It was a really bad mistake when people started making them
look more similar.

For example, tuple_size(T) div N =:= M doesn't raise an
exception when N is zero, it just *fails*.

Guards are part of pattern matching; in order to get efficient
pattern matching code it is important that the compiler should
be free to reorder matching and testing any way it likes; in
particular  G1, G2  need not be tested in the order G1 then G2
and often shouldn't be tested in that order.  But if these
could be called to user defined functions, such reordering
could break things.

It would probably be easier to design a new Erlang-like language
compiling to the same VM than to *coherently* unify guards and
expressions.