<div dir="ltr">Richard,<div><br></div><div>Why do you think "f(X, Y) when U = X+Y, U > 0 ; V = Y*X, V < 0 ->" is wrong? </div><div><br></div><div>I do think that this is ugly, and diminishes the boundary between function body and function header, and leads to cluttered programs.</div><div><div><br></div><div>But in a logical sense, in the same way input arguments are allocated private stack space (it is really heap at the OS level), even guards can create variables in the private stack; and apply logical conditions on them.<br></div><div><br></div><div>*I am not advocating this as a good thing to do, but thinking out loud*</div><div><br></div><div>Regards,</div><div>Theepan</div><div><br></div><div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 7, 2016 at 7:49 AM,  <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Team - Any idea?<br>
<br>
What it says: you may not use '=' in a guard.<br>
<br>
Come to think of it,<br>
> 60> is_integer(A = 5).<br>
is pretty horrible no matter where it occurs; it's one of<br>
the least likeable features of Erlang.<br>
<br>
As far as I know the reason '=' isn't allowed in guards<br>
is to avoid things like<br>
<br>
 f(X, Y) when U = X+Y, U > 0 ; V = Y*X, V < 0 -><br>
    ... is it OK to use U here? or V?<br>
<br>
That problem can surely be solved, just like 'case':<br>
if a variable is bound in every alternative of a guard,<br>
it's bound, otherwise it's visible but unusable.<br>
But before something like that could be adopted,<br>
'andalso' and 'orelse' and worse still 'and' and 'or'<br>
were allowed into guards, and things would have got<br>
even more tangled.<br>
<br>
<br>
<br>
</blockquote></div><br></div>