Note that, even if a function is NOW side effect free, if it's referenced using module:function syntax, it may later acquire side effects.<div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all">
<br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Sun, Dec 4, 2011 at 1:17 AM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com">ulf@feuerlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div>You should see guards as an extension of pattern matching.</div></div><div><br></div><div>If a guard function would have side-effects, the overall evaluation would most likely not be deterministic, and - most importantly perhaps - would be extremely difficult to understand and reason about. Ideally, the function should also be O(1), although a few O(N) guards, like length/1, are also allowed. For this reason, programmers can normally regard pattern-matching as extremely efficient, and use it extensively, trusting that the compiler will do a good job optimizing it.</div>
<div><br></div><div>It is correct that the compiler is not able to determine, at present, whether a function is referentially transparent. It also cannot determine the complexity of a function.</div><div><br></div><div>BR,</div>
<div>Ulf W</div><div><div class="h5"><br><div><div>On 4 Dec 2011, at 09:51, Barco You wrote:</div><br><blockquote type="cite"><p>But, if explaining in this way it has nothing to do with side-effect. It's just because the guard expression is stochastic rather than deterministic.</p>
<p>If having a deterministic function in the 'if' guard expression, we still get 'illegal guard expression'. According to the document provided by some guys in previous mails, the foundamental reason is that the erlang VM does not make sure whether a function in the guard expression has side-effect.</p>
<p>So, I hope to know why functions with side-effect can not be the guard expression.</p><p>Thank you all!<br>
Barco</p>
<div class="gmail_quote">On Dec 2, 2011 10:42 PM, "Barco You" <<a href="mailto:barcojie@gmail.com" target="_blank">barcojie@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Ooooh! Maybe I understand now!</p><p>It means that if the first branch is not satisfied, saying get 0.7, then random:uniform() would be evaluated again in the second branch and it possible to get a value less than 0.5, which then makes a paradox. Right?</p>
<p>In the contrast, with case statement, the condition is only evaluated once no matter whichever branch would be satisfied.</p><p>How smart erlang is, and how amazing you erlangers are!</p><p>Barco</p>
<div class="gmail_quote">On Dec 2, 2011 6:18 PM, "CGS" <<a href="mailto:cgsmcmlxxv@gmail.com" target="_blank">cgsmcmlxxv@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div text="#000000" bgcolor="#ffffff">
Just to make it clearer:<br>
<br>
The second condition is equivalent with the expression: "if the
value of random:uniform() is greater or equal to 0.5 then report
'bad'". In this case, if you entered with value 0.4 in the first
branch and modified it to 0.7 in the first branch, the second branch
should be executed as well. That is against the if statement purpose
which should report only one branch at the time as valid. Therefore,
Erlang requires for the compared values to be constant during the if
statement processing.<br>
<br>
CGS<br>
<br>
<br>
<br>
On 12/02/2011 11:06 AM, CGS wrote:
<blockquote type="cite">
If statement is not a block statement (to fix the variables values
at the entrance of the statement) in Erlang. That means, if an
uniform:random() value (say, 0.4) is used for checking the first
branch condition and the value is changed within the branch (say,
0.7), then you enter a paradox related to if the function should
be considered for the first or the second branch. To avoid this,
Erlang requires an assurance that the compared values do not
change while processing the if statement.<br>
<br>
CGS<br>
<br>
<br>
<br>
On 12/02/2011 10:56 AM, Barco You wrote:
<blockquote type="cite">Hi CGS,
<div><br>
</div>
<div>I can't understand your statement --- " if in the first
branch you use again random:uniform(), the second branch
condition can report an inaccurate result." Could you please
make it clearer? Thanks!</div>
<div><br>
</div>
<div>Hi Others,</div>
<div><br>
</div>
<div>Why functions with side effect can not be in the guard
expressions?</div>
<div><br>
</div>
<div><br>
</div>
<div>Thank you!</div>
<div>Barco<br>
<br>
<div class="gmail_quote"> On Fri, Dec 2, 2011 at 5:50 PM, CGS
<span dir="ltr"><<a href="mailto:cgsmcmlxxv@gmail.com" target="_blank">cgsmcmlxxv@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#ffffff"> Hi,<br>
<br>
To put in simple words for better understanding, you can
have only constant variables withing the guard
expression. That means, in your case, if in the first
branch you use again random:uniform(), the second branch
condition can report an inaccurate result.<br>
<br>
Alternatively, you can use case statement:<br>
<br>
case (random:uniform()<0.5) of<br>
true -> good;<br>
false -> bad<br>
end<br>
<br>
I hope this answer will help you.<br>
<br>
CGS
<div>
<div><br>
<br>
<br>
<br>
On 12/02/2011 10:30 AM, Barco You wrote: </div>
</div>
<blockquote type="cite">
<div>
<div>Why does the following expression
got "illegal guard expression" when compiling:
<div>X = 0.5,</div>
<div>if</div>
<div> random:uniform() < X -> %error
reported for this line</div>
<div> good;</div>
<div> true -></div>
<div> bad</div>
<div>end.</div>
<div><br>
</div>
<div>But if I change it to following expression,
it's ok:</div>
<div>
<div>X = 0.5,</div>
<div>Ran = random:uniform(),</div>
<div>if</div>
<div> Ran < X -> </div>
<div> good;</div>
<div> true -></div>
<div> bad</div>
<div>end.</div>
</div>
<div><br>
</div>
<div>BRs,</div>
<div>Barco</div>
</div>
</div>
<pre><fieldset></fieldset>
_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>