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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> http://erlang.org/mailman/listinfo/eeps >> >
_______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
