<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I see this change as making guards produce side effects because of
the code like:<br>
<pre wrap=""> case ... of
X when X ~ {A,B}, X /= {0,0} -> A + B
end
</pre>
(from "Binding semantics")<br>
The variables A and B are leaking into the case result, so these
variables are side-effects, right? Otherwise, with the way Erlang
is currently, guards are self-contained such that you can make
assumptions about the code executed after a guard, saying "this code
after this guard is not affected by the contents within the guard",
and that statement helps as you read Erlang code, since it is
functional and each statement returns a value... so guards currently
have distinct separation from the code they control. Your proposal
seems to remove that separation, which should make source code more
complex and will reduce the assumptions you can make about guard
statements. That is why I think it should reduce the testability of
Erlang code and eliminate optimization opportunities.<br>
<br>
On 04/13/2012 04:05 AM, Erik Søe Sørensen wrote:
<blockquote
cite="mid:CAO1s=UX2H8iFRSfxeq=byUR13+cCQjFoaGY366JApC=jm6sqKQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
Allowing side-effects in guards would certainly not be in the
Erlang spirit. I wouldn't dare suggesting that :-)<br>
The left-hand expression in a pattern test expression which occurs
within a guard is naturally(?) subject to the normal constraints
for what is allowed in a guard.<br>
I should perhaps state that explicitly in the specification.<br>
<br>
/Erik<br>
<br>
<div>Den 13. apr. 2012 02.54 skrev Michael Truog <span><<a
moz-do-not-send="true" href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>></span>:<br>
<blockquote>
<div> Your idea is interesting. However, doesn't it ruin the
simplicity of guards? It seems as if this proposal would
make guards generate side-effects which should impact both
testability and optimization opportunities. Isn't this a
concern?
<div>
<div><br>
<br>
On 04/12/2012 04:51 PM, Erik Søe Sørensen wrote: </div>
</div>
<blockquote type="cite">
<div>
<div>Hello all - <br>
<br>
Attached is a proposal to add to the Erlang language
an operator which allows for pattern matching to be
used in new contexts, in particular within guard
expressions. <br>
<br>
I hope the writeup to be in the expected format, as
well as describing a sufficiently interesting idea. <br>
<br>
Regards, <br>
Erik Søe Sørensen <br>
<br>
</div>
</div>
<pre>
_______________________________________________
eeps mailing list
<a moz-do-not-send="true" href="mailto:eeps@erlang.org">eeps@erlang.org</a>
<a moz-do-not-send="true" href="http://erlang.org/mailman/listinfo/eeps">http://erlang.org/mailman/listinfo/eeps</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>