<!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 understand the order of execution remains deterministic. My main
concern centers on the binding of a local variable, since you are
producing variables in a way that is currently impossible. I also
find it hard to argue for the benefits of producing local variables,
as has been described, with pattern matching in guard expressions.
So, the benefits of such changes are eluding me. There already
exists the binding of local variables within the typical pattern
matching expressions and we can depend on a guard expression never
altering the program's state, except to determine a single return
value that is boolean (I know there are problems mentioned in EEP
14, which I am choosing to ignore), used for either conditional
branching within a case statement, augmenting the pattern matching
that already exists there, or just providing the conditional
branching that exists within an if statement.<br>
<br>
The fact "=" is unable to bind a local variable within a guard
statement is a very positive thing, to me, because of the
assumptions you can make about guard statements, that would
otherwise not be possible. You know the scope of a guard statement
is limited to itself, such that it just returns a boolean and
no-more.<br>
<br>
I understand that in what you described the scope of the locally
bound variable is limited, as it would be in the currently supported
uses (i.e., ways that we can currently bind local variables in
patterns). That doesn't seem to justify breaking the current
barrier that exists within a guard statement, that prevents the
binding of local variables within guard statements.<br>
<br>
So, my concern is not about extra ordering constraints. The
potential for the proposal to eliminate optimization opportunities
is not something that I would fully explore. However, the most
basic problem would be for register allocation, where guard
expressions are currently very simple, so you can easily allocate
all registers to evaluate a guard as quickly as possible, if you so
choose, since you know all the guard expression contents is
short-lived. The guard statements are a closed system currently,
that just returns one of two values, both atoms, 'true' and
'false'. When you add local binding of variables to that, you
introduce an unknown variable lifetime, which depends on context,
making the code more complex and extending the scope of the guard's
impact on the code. I still see the local binding of the variable
within the guard statement as a side-effect, despite the fact this
is the lowest conceptual level where you would observe a side-effect
(i.e., as a variable binding). The nature of a side-effect is where
state in context A impacts state in context B. When you consider a
guard statement, and the proposal you are creating a unidirectional
side-effect from a guard statement (context A) and the code it
controls (context B). The side-effect is not as dramatic as ets or
the process dictionary, but it still breaks an intentional barrier
that has existed. I believe this absence of side-effects with guard
statements is a very positive thing within the Erlang language that
helps programmers make clear conditional statements that never get
blurred within pattern matching statements, so that both can be
combined, but always kept separate (in the current implementation).<br>
<br>
So, when I say guards are self-contained, I mean that they are a
closed-system, as described above. I am sure that my verbalization
is not formal when discussing these language features in the context
of abstract programming language design. I must also mention, I am
not a decision-maker, just a practitioner that is severely bothered
by guards becoming broken as described (i.e., the guards no longer
guard, but let variables through). The "~" operator reminds me of
perl, so perhaps I have bad memories, but I really have trouble
convincing myself that changes within your proposal are necessary
(as they relate to binding local variables within guard statements),
and I thought I should mention my concerns, since I would expect
that others share my concerns.<br>
<br>
<br>
On 04/14/2012 01:06 AM, Erik Søe Sørensen wrote:
<blockquote
cite="mid:CAO1s=UVkwt8fMGP6G9SEgm+ywN3ZRDyCpZFy2nzpfLPYZ4Sj+Q@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
Binding local variables is not usually regarded as a side effect
(in statically scoped languages such as Erlang).<br>
The "side effects reduce testability and optimation" concern, as I
know it, is rooted in the concern that a piece of code may execute
differently depending on which other parts of the code have
executed earlier, and in what order.<br>
In this context, there is nothing to fear from the proposed
change; the guarded body is executed if and only the guard
succeeds, and the guard may bind the variable if and only if the
whole guard succeeds. That is, there is still just one execution
history leading up to the execution of a guarded body: now it's
"pattern matches and pattern variables are bound; guard succeeds
and guard variables are bound; body is executed".<br>
Code other than the guarded expression won't be affected, since
the bound variables are only visible within that expression.<br>
Optimization opportunities could be reduced only to the extent
that the new construct adds new evaluation order constraints. I do
see one situation where that happens: when one guard expression in
a (','-connected) guard binds a variable which is later used by
another guard expression, as in "X~{ok,Y}, is_integer(Y)". In the
implementation I shall have to make sure that guard expressions
may still be reordered except when such dependencies actually
exist.<br>
<br>
Just to be sure I understand your concern about the
self-containedness of guards, when pattern have the same
"problem": I figure you're thinking of guards in the context of
'if'-expressions?<br>
Per-clause variable bindings in 'if'-expressions certainly would
be something new.<br>
(The language addition would make any 'case'-expressions
expressible using 'if', whereas presently only the opposite is the
case;<br>
case E0 of<br>
P1 when G1 -> E1;<br>
...<br>
end<br>
would be equivalent to<br>
Tmp = E0,<br>
if Tmp ~ P1, G1 -> E1;<br>
...<br>
end)<br>
<br>
/Erik<br>
<br>
<div>Den 14. apr. 2012 03.42 skrev Michael Truog <span><<a
moz-do-not-send="true" href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>></span>:<br>
<blockquote>
<div> I see this change as making guards produce side effects
because of the code like:<br>
<pre> 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.
<div>
<div><br>
<br>
On 04/13/2012 04:05 AM, Erik Søe Sørensen wrote:
<blockquote type="cite"> 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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>