EEP 52: Allow key and size expressions in map and binary matching

Fred Hebert mononcqc@REDACTED
Wed Jan 29 17:02:30 CET 2020


First question, the following example is given as illegal:

illegal_example6(Key, #{Key := Value}) -> Value.

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 (<<Size:8,Payload:((Size-1)*8)/binary,Rest/binary>>), is there an
implication that the following function call is valid and would match:

maybe_legal_example(#{key := NextKey, NextKey := Value}) -> Value.

Which given the map #{key => a, a => result} would return result. I don't
want to assume whether it would work, but the idea of "previously bound" is
a tad ambiguous in this case.


I would also definitely encourage the "absurd sizes" to come with a
compiler warning if an error is not acceptable.


I'm not familiar enough with core erlang to properly review that part of
the EEP, but I still have a few questions:

   - 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?
   - Do the new core erlang constructs allow the creation of invalid
   programs that could break VM semantics? I.e. Were things such as  primop
   'recv_peek_message'(), primop 'recv_next'(), and primop
   'remove_message'() 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)

The latter specifically could have wide-ranging impacts by opening up doors
that until now were not even doors.

On Wed, Jan 29, 2020 at 9:30 AM Raimo Niskanen <raimo+eeps@REDACTED>
wrote:

> New EEP:
>     https://erlang.org/eeps/eep-0052.html
>     https://github.com/erlang/eep/blob/master/eeps/eep-0052.md
>
> --
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20200129/38340a31/attachment.htm>


More information about the eeps mailing list