[erlang-questions] Illegal map key in pattern

[Dániel Szoboszlay]

So the documentation currently says:

Matching of key-value associations from maps is done as follows:
> #{ K := V } = M

Here M is any map. The key K must be an expression with bound variables or
> literals. V can be any pattern with either bound or unbound variables.


I think the problem with it is that the key should be a *pattern* with
bound variables, not an *expression*. Since #{K := V} is clearly a pattern,
it doesn't make sense to allow a part of it to be an expression (which is a
more generic thing than a pattern).

At least I wouldn't expect #{httpc:request("https://google.com/") := V} to
be a valid pattern, while httpc:request("https://google.com/") *is* an
expression with bound variables or literals.

But I would expect all patterns listed in
http://erlang.org/doc/reference_manual/expressions.html#patterns that
contain only bounded variables or literals to be usable as K. This would
include things like:
#{[X|Y] := Z} % assuming X and Y are bounded
#{1 + 2 := A}
#{"foo" ++ X := Y} % assuming X is bounded

This would make sense because the following patterns work just fine:
{[X|Y], Z}
{1 + 2, A}
{"foo" ++ X, Y}

By the way, one question that would still remain open is whether Erlang
shall allow operator = in key patterns:
#{(X = {foo, bar}) := Y}
Because {(X = {foo, bar}), Y} is a valid pattern, regardless of X being
bound or not. But this seems to be a lot less important issue.

Cheers,
Daniel

On Thu, 15 Aug 2019 at 15:06, Per Hedeland <per@REDACTED> wrote:

> 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
> >
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190815/52e63e42/attachment.htm>