<div dir="ltr">After having worked with really complex systems in very large projects, I've come to appreciate syntactic constructs signaling that nothing bad can ever happen there.<div><br></div><div>As Craig points out, 'case' is much more flexible, but this also potentially means that the expression evaluated by the case clause could contain gremlins. In an 'if' clause, only guard expressions are allowed, so only pure pattern matching - no side-effects allowed.</div><div><br></div><div>I think that's worth something.</div><div><br></div><div>BR,</div><div>Ulf</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 15, 2021 at 6:48 AM zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, Michael.<br>
<br>
On 2021/08/15 6:44, Michael P. wrote:<br>
> I once stumbled over someone's Erlang style guide,<br>
> they wanted no `if`.<br>
> It was not very well explained why,<br>
...<br>
> Is if not merely "syntactic sugar" for<br>
> a fun/0 with guarded clauses?<br>
<br>
The main reason people dislike `if` is that it applies to boolean <br>
comparison situations where `case` provides for a much more interesting <br>
semantic for branching. `if` is most often best used in situations where <br>
you have a *range* of values you want to completely cover:<br>
<br>
   if<br>
      X > Y -> do_something();<br>
      X = Y -> do_something_else();<br>
      Y < Y -> do_yet_another_thing()<br>
   end<br>
<br>
This is *not* the same as a simpler boolean case<br>
<br>
   case X > Y of<br>
     true  -> foo();<br>
     false -> bar()<br>
   end<br>
<br>
`if` enables more complex ranges and the drop-through nature of the <br>
various clauses are occasionally very useful in reducing some evaluation <br>
of complex checks that tend to create even messier and more complex code <br>
to something easy to read.<br>
<br>
You can still always do the same thing with a `case` using guards, <br>
though -- and as you mentioned you *could* do the same with funs, but <br>
that's a bit crazy as you're invoking the lambda machinery for really no <br>
reason as there is motivation to create and execute a function in place <br>
when you just want to perform a simple comparison.<br>
<br>
In Erlang it is much more common to use `case` for just about everything <br>
and most programs don't have a single `if` in them at all unless they <br>
are written by people coming to Erlang from another language that only <br>
has `if` (and then they wind up often misunderstanding the semantics of <br>
Erlang's version of `if`, so you see the default `true` clause pop up, <br>
which makes the newcomer think "this is silly, why does Erlang's `if` <br>
work this way?" because using `if` that was *is* silly in most cases).<br>
<br>
Anyway... generally speaking `case` is much more powerful than `if`, and <br>
`if` has a very niche use case for which it is a very concise way of <br>
doing comparisons within a function body that carries some context you <br>
need to involve in the `if` test clauses that would otherwise be <br>
cumbersome to pass along to a special function whose only job was to <br>
check something in guards.<br>
<br>
-Craig<br>
</blockquote></div>