<div dir="ltr"><div>First question, the following example is given as illegal:</div><div><pre><code>illegal_example6(Key, #{Key := Value}) -> Value.
</code></pre></div><div>On the other hand, the text mentions this "All variables used in a key expression must be previously bound." If we go from the binary pattern match (<code><<Size:8,Payload:((Size-1)*8)/binary,Rest/binary>></code>), is there an implication that the following function call is valid and would match:</div><div><pre><code>maybe_legal_example(#{key := NextKey, NextKey := Value}) -> Value.</code></pre></div><div>Which given the map <span style="font-family:monospace">#{key => a, a => result}</span> would return <span style="font-family:monospace">result</span>. I don't want to assume whether it would work, but the idea of "previously bound" is a tad ambiguous in this case.</div><div><br></div><div><br></div><div>I would also definitely encourage the "absurd sizes" to come with a compiler warning if an error is not acceptable.</div><div><br></div><div><br></div><div>I'm not familiar enough with core erlang to properly review that part of the EEP, but I still have a few questions:</div><div><ul><li> Is there an expectation that the larger core erlang constructs will compile to the same underlying VM instructions and be as performant as they are right now, since it's mostly exploding the current higher-level operations into underlying ones?</li><li>Do the new core erlang constructs allow the creation of invalid programs that could break VM semantics? I.e. Were things such as  <code>primop 'recv_peek_message'()</code>, <code>primop 'recv_next'(), </code>and <code>primop 'remove_message'()</code> already allowed, or do they now allow someone to generate core-erlang programs that would re-read the same message off a mailbox multiple times, or introspect the list more fully without actually extracting messages without further VM support (i.e. process_info()-based introspection no longer needed)</li></ul><div>The latter specifically could have wide-ranging impacts by opening up doors that until now were not even doors.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2020 at 9:30 AM Raimo Niskanen <<a href="mailto:raimo%2Beeps@erlang.org">raimo+eeps@erlang.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">New EEP:<br>
    <a href="https://erlang.org/eeps/eep-0052.html" rel="noreferrer" target="_blank">https://erlang.org/eeps/eep-0052.html</a><br>
    <a href="https://github.com/erlang/eep/blob/master/eeps/eep-0052.md" rel="noreferrer" target="_blank">https://github.com/erlang/eep/blob/master/eeps/eep-0052.md</a><br>
<br>
-- <br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
</blockquote></div>