[erlang-questions] style question - best way to test multiple non-guard conditions sequentially
Richard A. O'Keefe
Fri Jun 21 01:01:49 CEST 2013
On 21/06/2013, at 3:29 AM, Jonathan Leivent wrote:
The ?BREAK is rather horrible; to my mind, far more horrible than nice
clean obvious closures.
>> 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
of true -> A1
; false ->
of true -> A2
; false ->
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
More information about the erlang-questions