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

[Fred Hebert]

Agh, follow-up question:

Any impact of these things on the ability to use them in match
specifications and fun2ms equivalents, or what the errors could be on using
these in such a context?

On Wed, Jan 29, 2020 at 11:02 AM Fred Hebert <mononcqc@REDACTED> wrote:

> 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/b064aedc/attachment.htm>