<div dir="ltr">So the documentation currently says:<div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Matching of key-value associations from maps is done as follows:<br><span class="gmail-hljs-comment" style="color:rgb(160,161,167);font-style:italic">#{ K := V } = M</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div>I think the problem with it is that the key should be a <b>pattern</b> with bound variables, not an <b>expression</b>. Since <font face="monospace">#{K := V}</font> 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).<div><br></div><div>At least I wouldn't expect <font face="monospace">#{httpc:request("<a href="https://google.com/">https://google.com/</a>") := V}</font> to be a valid pattern, while <span style="font-family:monospace">httpc:request("<a href="https://google.com/">https://google.com/</a>")</span> <b>is</b> an expression with bound variables or literals.</div><div><br></div><div>But I would expect all patterns listed in <a href="http://erlang.org/doc/reference_manual/expressions.html#patterns">http://erlang.org/doc/reference_manual/expressions.html#patterns</a> that contain only bounded variables or literals to be usable as K. This would include things like:</div><div><font face="monospace">#{[X|Y] := Z} % assuming X and Y are bounded</font></div><div><font face="monospace">#{1 + 2 := A}</font></div><div><font face="monospace">#{"foo" ++ X := Y}</font><span style="font-family:monospace"> </span><span style="font-family:monospace">% assuming X is bounded</span></div><div><br></div><div>This would make sense because the following patterns work just fine:</div><div><div><font face="monospace">{[X|Y], Z}</font></div><div><font face="monospace">{1 + 2, A}</font></div><div><font face="monospace">{"foo" ++ X, Y}</font></div></div><div><br></div><div>By the way, one question that would still remain open is whether Erlang shall allow operator = in key patterns:</div><div><font face="monospace">#{(X = {foo, bar}) := Y}</font></div><div>Because <font face="monospace">{(X = {foo, bar}), Y}</font> is a valid pattern, regardless of <font face="monospace">X</font> being bound or not. But this seems to be a lot less important issue.</div><div><br></div><div>Cheers,</div><div>Daniel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Aug 2019 at 15:06, Per Hedeland <<a href="mailto:per@hedeland.org">per@hedeland.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-08-15 14:12, Björn-Egil Dahlberg wrote:<br>
> Den mån 5 aug. 2019 kl 13:45 skrev Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org" target="_blank">raimo+erlang-questions@erlang.org</a> <mailto:<a href="mailto:raimo%252Berlang-questions@erlang.org" target="_blank">raimo%2Berlang-questions@erlang.org</a>>>:<br>
> <br>
> ><br>
> > But maybe it's "just" something that was a challenge to implement, and<br>
> > will be fixed to match the current documentation in a future release...<br>
> <br>
> I think it is precisely like that. It is documented as it was intended,<br>
> but implementing it was a challenge so it got only partly implemented.<br>
> (constructing a new term for map lookup in the context of a pattern match<br>
> proved an unexpectedly hard problem, I guess)<br>
> <br>
> <br>
> IIRC the case that was troublesome was the failure case, say<br>
> <br>
> K = a<br>
> <br>
> case Map of<br>
> #{ K + 1 := V } -> V;<br>
> ...<br>
> <br>
> 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.<br>
<br>
Hm, is this really different from other expressions in a pattern?<br>
<br>
1> K = a.<br>
a<br>
2> Map = b.<br>
b<br>
3> case Map of K + 1 -> true; _ -> false end.<br>
* 1: illegal pattern<br>
<br>
Which is because<br>
<br>
An arithmetic expression can be used within a pattern if it meets<br>
both of the following two conditions:<br>
<br>
o It uses only numeric or bitwise operators.<br>
o Its value can be evaluated to a constant when complied.<br>
<br>
I.e. it seems to me that this restriction (and compile-time error)<br>
"should just apply" also to map keys in patterns - it's still "an<br>
aritmetic expression within a pattern". Are there other failure cases,<br>
that would cause problems for expressions that don't violate this<br>
restriction?<br>
<br>
--Per<br>
<br>
> 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 <br>
> 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 ^^<br>
> <br>
> In other words - it is not implemented because we, well I, missed this case when defining the semantics.<br>
> <br>
> My bad.<br>
> Björn-Egil<br>
> <br>
> <br>
> So it is a known limitation, to us that know it ;-)<br>
> unfortunately not nicely documented,<br>
> and the goal is to fix it some day...<br>
> <br>
> <a href="http://erlang.org/pipermail/erlang-questions/2016-May/089269.html" rel="noreferrer" target="_blank">http://erlang.org/pipermail/erlang-questions/2016-May/089269.html</a><br>
> <br>
> <br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> <br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>