I agree on these points - I view guards and their patterns as one entity, and hadn't expected that objection at all.<br>I'm glad to hear arguments that the concern can't be that common.<br>(I have many concerns that possibly aren't that widespread; knowing that there is one around that i can't see the point of at all would make me wonder what threats I'm overlooking.)<br>
<br><div class="gmail_quote">Den 16. apr. 2012 06.06 skrev Richard O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
On 16/04/2012, at 1:05 PM, Michael Truog wrote:<br>
> So you believe that pattern matching in guards requires binding local variables to be useful, right?<br>
<br>
</div>No, I just believe that it makes them *more* useful.<br>
<div class="im"><br>
> You do not seem to be concerned about this change causing guards to create side-effects, where they previously where unable to do so.<br>
<br>
</div>Come off it! To start with, binding a variable is not a side effect.<br>
But consider: apart from 'if', guards are not found on their own, but<br>
has one part of a Pattern when Guard combination. If the Pattern part<br>
can bind variables, what is so evil about the Guard part doing so?<br>
<div class="im"><br>
> Are we just not aware or recognizing any potential negative aspects of binding variables within guard statements, or do we just accept them as a necessary evil?<br>
<br>
</div>I don't know who "we" are here. I can imagine no negative aspects of binding variables<br>
within guards that are not also negative aspects of binding variables within patterns.<br>
<br>
Erlang was strongly influenced by Strand 88 which owed a fair bit to Parlog.<br>
In Parlog, a clause has the form<br>
<br>
H := G1, ..., Gm : Body.<br>
<br>
where ":" is the "commit" operator, and is left out if m = 0, the Gi being<br>
the guards., and a Body is<br>
- Body1 , Body2 "parallel AND"<br>
- Body1 & Body2 "sequental AND"<br>
- a call<br>
Parlog guards are rather more general than Erlang guards, and it was<br>
implementation experience with nested layers of processes that suggested<br>
the simplified "flat" guards found in GHC, FCP, and Erlang. But in all<br>
the concurrent logic programming languages, including GHC, FCP, and Parlog,<br>
guards may include pattern-matches that bind variables.<br>
<br>
I never heard of any negative consequences of _that_.<br>
<div class="im"><br>
> To me, the idea of guard statements binding variables seems to contradict both the purpose/name "guard" since it is guarding state, and binding a variable within the guard statement would be allowing the state to leak out.<br>
<br>
</div>There are no guard statements, only guard tests. And pattern matching is<br>
a perfectly good test. Consider two clauses:<br>
<br>
f(X = Y) when true -> g(X).<br>
<br>
f(Y) when X = Y -> g(X).<br>
<br>
How does the second clause "leak" any "state" that the first one doesn't?<br>
<br>
For that matter, these days Haskell has "pattern guards":<br>
<br>
<clause head> | <pattern> <- <expr>{, ...} = <expr><br>
<br>
See <a href="http://www.haskell.org/haskellwiki/Pattern_guard" target="_blank">http://www.haskell.org/haskellwiki/Pattern_guard</a><br>
<br>
Nobody in the Haskell community thinks of this as "leaking" any kind of "state",<br>
and Haskell is notably purer than Erlang...<br>
<div class="im">><br>
> I don't want to push this point if it isn't regarded as a problem, but I just wanted to understand how you see it.<br>
<br>
</div>Here's how I see it:<br>
(1) The concurrent programming languages preceding Erlang allowed<br>
pattern matches in guards, using "=". There were no conceptual<br>
difficulties with this.<br>
(2) I have never seen any explanation of why Erlang didn't.<br>
(3) It is technically possible to rewrite Erlang clauses with<br>
pattern matching to ones without, at a great loss of clarity.<br>
<br>
f(Args) when T1, P = E, T2 -> Body<br>
=><br>
f(Args) when T1 -> try E of P when T2 -> Body<br>
catch _ -> rest_f(Args) end;<br>
f(Args) -> rest_f(Args).<br>
<br>
f'(Args, P) when T2 -> Body;<br>
f'(Args, _) -> rest_f(Args).<br>
<br>
I hope that gives you the idea. No "state" can be "leaked" by<br>
pattern guards that cannot be "leaked" in this way.<br>
(4) Pattern guards in Haskell don't seem to cause any problems.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
</div></div></blockquote></div><br>