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 class="gmail_quote">Den 14. apr. 2012 03.42 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"><u></u>

  
    
  
  <div bgcolor="#ffffff" text="#000000">
    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 class="h5"><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 href="mailto:mjtruog@gmail.com" target="_blank">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 href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/eeps" target="_blank">http://erlang.org/mailman/listinfo/eeps</a>
</pre>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br>