[eeps] EEP XXX: Pattern-test operator

[Erik Søe Sørensen]

Binding local variables is not usually regarded as a side effect (in
statically scoped languages such as Erlang).
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.
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".
Code other than the guarded expression won't be affected, since the bound
variables are only visible within that expression.
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.

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?
Per-clause variable bindings in 'if'-expressions certainly would be
something new.
(The language addition would make any 'case'-expressions expressible using
'if', whereas presently only the opposite is the case;
  case E0 of
    P1 when G1 -> E1;
    ...
  end
would be equivalent to
  Tmp = E0,
  if Tmp ~ P1, G1 -> E1;
     ...
  end)

/Erik

Den 14. apr. 2012 03.42 skrev Michael Truog <mjtruog@REDACTED>:

> **
> I see this change as making guards produce side effects because of the
> code like:
>
>     case ... of
>       X  when  X ~ {A,B}, X /= {0,0} -> A + B
>     end
>
> (from "Binding semantics")
> 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.
>
>
> On 04/13/2012 04:05 AM, Erik Søe Sørensen wrote:
>
> Allowing side-effects in guards would certainly not be in the Erlang
> spirit.  I wouldn't dare suggesting that :-)
> 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.
> I should perhaps state that explicitly in the specification.
>
> /Erik
>
> Den 13. apr. 2012 02.54 skrev Michael Truog <mjtruog@REDACTED>:
>
>  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?
>
>
> On 04/12/2012 04:51 PM, Erik Søe Sørensen wrote:
>
>  Hello all -
>
> 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.
>
> I hope the writeup to be in the expected format, as well as describing a
> sufficiently interesting idea.
>
> Regards,
> Erik Søe Sørensen
>
>
> _______________________________________________
> eeps mailing listeeps@REDACTED://erlang.org/mailman/listinfo/eeps
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20120414/802c7b58/attachment.htm>