<div class="gmail_quote">Den 16. apr. 2012 10.51 skrev Michael Truog <span dir="ltr"><<a href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 04/15/2012 09:06 PM, Richard O'Keefe wrote:<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>
> No, I just believe that it makes them *more* useful.<br>
><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>
> 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>When you consider a side-effect as defined with the simplest possible explanation ("a side-effect is where state in context A impacts state in context B"), it should be easy to see that a variable created within a guard that is then used within a function body is a side-effect. I understand that normal patterns can bind variables. Why must guards now bind variables also?<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>
> 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>My concern is that you never heard of negative consequences because no one cared. You are arguing with examples from Haskell and Parlog which both found no wide-spread use outside of academia.</blockquote><div><br>
Saying that there's an abstraction leak in a wide-spread Haskell component and no-one in the Haskell community cares about it is like saying that the crew of the ISS doesn't care if there's a leak in their, well, anything.<br>
I find the mention of Haskell in this context quite appropriate. <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I know Haskell has tried very hard to be applied outside of academia, however, it never really seems to stick to any problems, so it seems to retain status as a language that is a solution in search of a problem to solve (any problem will do). You don't need to bother listing obscure research projects done in Haskell here.<br>
</blockquote><div> </div><div>The XKCD's April Fool's prank recently was at least partially done in Haskell. Oh, and Facebook, Google and a number of banks use the language internally. Ericsson too.<br><br></div><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>
>> 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>
> 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>
</div>I agree that both can be written with the changes mentioned in the proposal to add variable bindings to guards. That is part of the reason it appears to be an unnecessary addition that is just meant to complicate Erlang code and the Erlang VM.<br>
</blockquote><div><br>The Erlang VM would come to no harm.<br>
(I believe I have enough knowledge of BEAM bytecode to guarantee you this.)<br><br> </div><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>
> 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>Arguing that no one within the Haskell community thought about this doesn't seem relevant. Erlang as a language is at a different place than where Haskell is. I don't see these as differences that should be resolved so that Erlang should be more like Haskell. The purity argument about Haskell means very little to someone who is interested in solving problems outside of academia. If Haskell was completely pure, it would never write to the screen, and we would know very little about the language... wouldn't we?<br>
</blockquote><div> </div><div>Yes, Haskell can do I/O. If it couldn't, it'd be just as irrelevant as you're trying to paint it.<br>But what it also does is keep the I/O parts separate from the parts which aren't intended to do I/O. And that separation is quite pure. The purity argument about Haskell means quite a lot to some which are interested in solving problems outside of academia and wish to use less of their problem solving time on hunting bugs caused by unintended side effects. Which, on the face of it, would be something you care about too.<br>
</div><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>
>> 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>
> 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>
><br>
</div>My argument is that if patterns already provide us variable bindings, why weaken Erlang guards to also bind variables. I would rather have a stronger guarantee that state from a guard will not affect the context it controls. I do not think the aspect in the Haskell language offers a convincing argument for binding variables in guards (otherwise, that would be like saying "Hey, some academics did something in a language the industry doesn't use, but it seems conceptually pure, so lets imitate them."). Implementing something in Haskell does not create a requirement that it must be implemented in Erlang.</blockquote>
<div> </div><div>Certainly not, but countering a purity concern with experience from that community is not far-fetched.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A requirement that Haskell features be implemented in Erlang would only help Haskell programmers, but if Haskell programmers don't often work outside of academia, why would they use Erlang to solve real problems?<br>
</blockquote></div><br>/Erik (not a practising Haskell programmer myself, but I do know the paradigm well enough to have respect.)<br>