4 ms·
Mostly the reason for that is to allow the compiler to optimise the order of evaluation of the conditions. If you could put functions with side-effects in there
by tb 19y ago
Mostly the reason for that is to allow the compiler to optimise the order of evaluation of the conditions. If you could put functions with side-effects in there then it would be impossible to do that since the compiler would have to guarantee some kind of consistent evaluation order.
There have been proposals for some way to mark user-defined functions as side-effect free and thus allow them to be used in guards. None has had acceptance from the core Erlang developers yet.
In any case this is not usually too much of a problem. The Erlang idiom is to use 'case' instead of 'if' in most cases (no pun intended) and where a calculated value is needed then just assign it to a variable beforehand - not quite as pretty I agree but no big deal.
- lg 19y agoSo my small problem sounds like a bigger problem. Why won't Erlang let me specify the order of evaluation? You know, like, left to right?
- bayareaguy 19y agoDumb question: Erlang computations are supposed to be side-effect free right? If they are, why does order of evaluation matter?
- lg 19y agoSeems you're right. That was a nice foray. Back to Scheme I go...
- tb 19y agoIf you had a piece of code like this: case my_function(Foo) of some_result -> do_something(A); some_other_result -> do_something(B); _ -> do_default_case() end Why do you care if the output of my_function(Foo) is compared to some_result first or some_other_result first?