<div class="gmail_quote">2009/1/29 Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div><br>
</div><div>> Is this cause of 'side effects free' guards nature?<br>
<br>
</div>Not really.  It's because guards aren't true or false;<br>
they succeed or fail.  (Blurring this distinction was a<br>
really bad idea.)</blockquote><div><br>This point Richard is making is actually very basic and important, guards aren't true or false but rather they either succeed or fail. Just to restate it! Guards are really just the bits of pattern matching which can't easily be written in the pattern. So really the only way a clause is chosen is by pattern matching alone.<br>

<br>In this context it was quite reasonable to add the feature that an exception in a guard was equivalent to the guard failing. It also explains why some guard *tests* aren't really valid as expressions, for example the *test* float(F) tests whether F is a float, while the *expression* float(F) means convert F to a float (if it is an integer).<br>
<br>Unfortunately adding boolean operators, while being useful, makes guards look like expressions and blurs the distinction between expressions and guard tests. It also complicates the semantics of exceptions in guards.<br>
<br>Robert<br><br>P.S. Yes I know there exists ways of writing patterns were the tests are included in the pattern, I have seen some, but I think they the pattern very hard to read. Having them in a separate guard does make it easier to read (but maybe harder to understand).<br>
<br>

</div></div>