[erlang-questions] Maps

Robert Virding robert.virding@REDACTED
Thu May 9 22:56:42 CEST 2013


Even before taking a really deep dive into studying the EEP one thing I can immediately say: get rid of this having both equal and match and USE ONLY MATCH . Keys are the same when they match. Period. This paragraph: 

If key K does not equal any existing key in the map, a new association will be created from key K to value V . If key K is equal to an existing key in map M its associated value will be replaced by the new value V and the new key K will replace the old key if the key does not match . In both cases the evaluated map expression will return a new map. 

is weird. Yes I know what it means but it is not intuitive. When keys are replaced or not replaced when they are equal is not can seem very strange to those not deep into erlang semantics. 

Push 
Yes, I think we made an error with the different types of equalities and that comparisons covert integers to floats. With 20-20 hindsight I would prefer ==,/=,<,=<,>,>= to ONLY work on numbers and convert while another set @==,@/=,@<,@=<,@>,@>= (say) to work on terms and never convert. 
Pop 

While we are at it I think the evaluation order for keys and values should be defined as left-to-right. The rest of erlang is so why not here? 

Robert 

----- Original Message -----

> From: "Björn-Egil Dahlberg" <egil@REDACTED>

> Hi everyone!

> We finally have a Maps EEP for you. This will get you an idea on what
> we are working on. Some of the ideas presented here was presented at
> Erlang Factory SF Bay Area 2013.

> I am sure that there will be some discussions about the contents of
> this EEP and I hope the discussions will be both fruitful and
> civilized.

> The journey of Maps and this EEP has been long and by no means a
> straight-forward or continuous one. I had a crystal clear picture of
> what I wanted Maps to be when we first started discussing it within
> OTP about two-three years ago. This EEP resembles that vision but it
> has had a lot of contributions of other ideas from both within and
> outside of OTP.

> The idea was a functional data-type, a syntax aware mapping of
> key-value associations with pattern matching. A syntax similar to
> records but without the hazzle of compile-time dependency and with
> arbitrary terms as keys. Order was not important and it could be
> implemented with a Hash-Array-Mapped-Trie with good performance and
> memory trade-offs. This was not an approach to replace records. It
> was meant to replace records where suitable and in other regards not
> be a replacement but its own thing .

> From the community there has been many wishes of a Map like data-type
> and a few suggestions. The one suggestion that stands out is of
> course the Frames proposal from Richard O'Keefe. It is the most
> complete proposal I've seen and is very well thought out. Its goal
> is to be a record replacement and the proposal satisfies this goal
> very well.

> - If Frames are that good, why a separate EEP?
> - It boils down to goals and constraints.

> A record replacement is just that, a replacement.
> It's like asking the question, "What do we have?" instead of "What
> can we get?"
> The instant rebuttal would be "What do we need?" I say Maps.

> Frames has certainly influenced Maps. In many regards Maps also
> encompasses Frames but Maps tries to do more. I think the most
> significant difference would be, arbitrary terms as keys and how
> many different keys we would have in a Map. In the end I believe
> they are two different things and have different goals.

> Some Notes and Disclaimers:

> Later iterations of Maps has gone through some changes, most
> significantly,

> * From a set of key-values to a ordered set of key-value associations

> I was originally against this change since it forces restrictions on
> the implementation and it illuminates the lack of distinction
> between arithmetic order and term order, i.e. the problem of mixing
> integer and float types as keys in a tree. However, I was later
> persuaded that key ordering is necessary. We have to respect the
> totalitarian order of terms.

> Considerations has been made on how to, if at all possible, apply
> Frames characteristics to Maps. Most significantly memory space and
> key-sharing characteristics. This is not detailed in the EEP though,
> just mentioned.

> The function interface has had many revisions as well. At some stage
> the API was considered to be a drop-in-replacement for `dict` and
> thus would have the same function-names. This goal/constraint was
> dropped by Technical Board decision recently.

> From the very beginning Maps was envisioned to have the ability to
> bind variables derived from the environment. Like this:

> function(K1, #{ K1 := K2, K2 := V }) -> V.

> This feature is a beast. Powerful and scary. It is not confined to
> only Maps but should also be applicable to other types as well:

> function(Skip, <<_:Skip/binary, Value:Size, _/bits>>, Size) -> Value.

> It is uncertain how effective such an implementation would be and in
> the end we might not want this feature at all.

> In this EEP we will describe syntax and semantics of Maps but very
> little is disclosed of its actual implementation. Current prototypes
> stems from using sparse tuples in a HAMT-like data structure and
> tuple-like data structures. The HAMT-like data structure is
> discontinued and will be replaced by some ordered tree.

> The proposal is included as an attachment but can also be viewed at
> this git-repository:
> https://github.com/psyeugenic/eep/blob/egil/maps/eeps/eep-0043.md

> Regards,
> Björn-Egil Dahlberg
> Erlang/OTP
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130509/428f8ea1/attachment.htm>


More information about the erlang-questions mailing list