[erlang-bugs] Match error when mapping a list of maps with anonymous functions in the shell

[Fred Hebert]

So I see the original ones:

        [X=not_ok,(fun (Y) -> X = Y end)(ok)].
        [X=not_ok,case ok of ok -> X = ok; _ -> ok end].

Here's an interesting experiment with these to hilight the order of
operation vs. scoping relationship, tried both in the shell and with the
compiler (and HiPE):

- [A=1,B=A,C=A] => error: variable 'A' is unbound
- [A=B,B=1,C=B] => error: variable 'B' is unbound
- [A=B,B=C,C=1] => error: variable 'B' is unbound

If no scope is present at first, the expressions will all fail. However,
if I bind A=1 before building the list:

- [A=1,B=A,C=A] => [1,1,1]
- [A=B,B=1,C=B] => error: variable 'B' is unbound
- [A=B,B=A,C=B] => error: variable 'B' is unbound
- [A=B,B=C,C=1] => error: variable 'B' is unbound

According to this kind of behavior, it does look like no order of
evaluation is assumed for each of the entires of a list, similarly for
tuples and lists declared as cons cells:

- {A=1,B=A,C=A} => error: variable 'A' is unbound
- [A=1 | [B=A | [C=A | []]]] => error: variable 'A' is unbound

Given that kind of behaior, I'd have to agree with you, Anthony, that in
both original cases, the right hand side 'X' shouldn't be matched,
unless we're going to change some deeper (and apparently) stable
semantics in the language there.

(Incidentally, I wonder if the changes to pattern matching
recommended/planned for maps that would start allowing these use cases
also.)

Regards,
Fred.

On 05/04, Anthony Ramine wrote:
> Because it makes the evaluation order relevant to scoping, while it shouldn’t be.
> 
> Compare with:
> 
> 	[(fun (Y) -> X = Y end)(ok),X=not_ok].
> 	[case ok of ok -> X = ok; _ -> ok end,X=not_ok].
> 
> Also, Björn-Egil confirmed that the expression with the fun is indeed a bug. Nobody confirmed anything for the case with the unsafe X though.
> 
> The Erlang documentation agrees that there is no defined evaluation order.
> 
> And erl_lint agrees with me that the X in the fun shouldn’t match against the previous X, claiming both are unused.
> 
> In both cases, I think the X in the fun (or the case) shouldn’t match against anything and just be declared as unused by erl_lint.
> 
> Ideally, such code would just be forbidden by erl_lint because it is confusing.
> 
> -- 
> Anthony Ramine
> 
> Le 4 mai 2014 à 13:00, Kostis Sagonas <kostis@REDACTED> a écrit :
> 
> > On 05/04/2014 11:13 AM, Anthony Ramine wrote:
> >> Now the only remaining bug concerns some edge cases:
> >> 
> >> 	[X=not_ok,(fun (Y) -> X = Y end)(ok)].
> >> 	[X=not_ok,case ok of ok -> X = ok; _ -> ok end].
> >> 
> >> In my opinion, in both cases the second X shouldn’t be matched against the first.
> > 
> > Why not?  Care to elaborate what is your rationale and what should happen in these cases?
> > 
> > Kostis
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugs@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-bugs
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs