[erlang-questions] Illegal map key in pattern

[Per Hedeland]

On 2019-08-15 14:12, Björn-Egil Dahlberg wrote:
> Den mån 5 aug. 2019 kl 13:45 skrev Raimo Niskanen <raimo+erlang-questions@REDACTED <mailto:raimo%2Berlang-questions@REDACTED>>:
> 
>      >
>      > But maybe it's "just" something that was a challenge to implement, and
>      > will be fixed to match the current documentation in a future release...
> 
>     I think it is precisely like that.  It is documented as it was intended,
>     but implementing it was a challenge so it got only partly implemented.
>     (constructing a new term for map lookup in the context of a pattern match
>     proved an unexpectedly hard problem, I guess)
> 
> 
> IIRC the case that was troublesome was the failure case, say
> 
> K = a
> 
> case Map of
>     #{ K + 1 := V } -> V;
>     ...
> 
> Meaning it is essentially no trouble to evaluate the key expression before the case expression, however the semantics for what should happen if the key expression fails were never really defined.

Hm, is this really different from other expressions in a pattern?

1> K = a.
a
2> Map = b.
b
3> case Map of K + 1 -> true; _ -> false end.
* 1: illegal pattern

Which is because

    An arithmetic expression can be used within a pattern if it meets
    both of the following two conditions:

    o It uses only numeric or bitwise operators.
    o Its value can be evaluated to a constant when complied.

I.e. it seems to me that this restriction (and compile-time error)
"should just apply" also to map keys in patterns - it's still "an
aritmetic expression within a pattern". Are there other failure cases,
that would cause problems for expressions that don't violate this
restriction?

--Per

> The easy option it just to throw an exception and that makes some sort of sense, but it could make more sense that we say "the pattern does not match" and then test the next clause in the case 
> expression. This latter option is also a bit harder to implement ofc. The core and kernel language does not really expect this behaviour :) go and figure ^^
> 
> In other words - it is not implemented because we, well I, missed this case when defining the semantics.
> 
> My bad.
> Björn-Egil
> 
> 
>     So it is a known limitation, to us that know it ;-)
>     unfortunately not nicely documented,
>     and the goal is to fix it some day...
> 
>     http://erlang.org/pipermail/erlang-questions/2016-May/089269.html
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>