[eeps] EEP XXX: Pattern-test operator

[Michael Truog]

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 <mailto: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 list
>>     eeps@REDACTED <mailto:eeps@REDACTED>
>>     http://erlang.org/mailman/listinfo/eeps
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20120413/f7226b1d/attachment.htm>