[erlang-questions] Maps branch and disclaimers

[Robert Virding]

Great! But I do have some comments (of course): 

- I would keep the function names from the dict module where possible. This to make it easier to convert. 

- I definitely agree about creating true term ordering comparison operators to complement =:= and =/=. But as I am more used to the prolog set (@==, @/=, @>, @>=, @< and @=<) I would much prefer to have them instead. They at least start with the same character. Anyway create the operators and define maps to use them, and then fix dict/orddict/gb_trees to use them as well so they are compatible. I could survive potential backwards compatibility problems with them to achieve consistency. 

- I also definitely agree to keep the syntactic footprint to a minimum and introduce as little new syntax as possible. 

- For map comprehensions I would NOT use <- as the generator operator as it tells me we are generating elements from a list. Binaries got a new operator and I think maps should as well, for example <:, or something else. 

Robert 

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

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

> Hi!

> Here you go, Maps!

> I've pushed a Maps branch to Erlang/OTPs repository at GitHub.

> To get the branch,

> git fetch git@REDACTED:erlang/otp.git egil/maps/eep-implementation

> or find it at https://github.com/erlang/otp/tree/egil/maps/eep-implementation

> I want to state the following so there is no room for uncertainty:
> - This branch contains a development stage of the experimental Maps feature
> for Erlang.

> This means:
> - Do not use it in production since it is not stable,
> - Do not base any git branch on this branch since it will most likely be
> rebased,
> - and finally, we reserve the right to change any API or interfaces to Maps
> currently implemented.

> The implementation is based on EEP 43 - Maps, see
> http://github.com/erlang/eep/blob/master/eeps/eep-0043.md , for details.

> What is implemented?

> The maps module API and erlang guard BIFs as defined in the EEP are
> implemented. There are however some sematic mismatches with the EEP. I think
> those are where the definition contradict itself. For instance maps:is_key/1
> compares with =:= as stated first in the definition but the later example
> uses lists:keymember which compares with ==.

> The syntax and all what that entails is implemented. The compiler will handle
> the map syntax and produce loadable beam-code. I believe this is what people
> want to test and is what I want people to test. Test the usability that is.

> I recommend people look at the EEP for information and also the testsuite
> located at erts/emulator/test/map_SUITE.erl for information on how to use
> Maps since no other documentation is available.

> Roughly,
> M0 = #{ key => Value1, "key" => Value2}, % for construction.
> M1 = M1#{ "key" := Value3, <<"key">> => Value4 }, % for updates
> #{ "key" := V } = M1. % for matching

> Where the operator '=>' (assoc operator) is used for extending and creating
> new Maps and the operator ':=' is used to update existing key/values. The
> ':=' operator is the only operator allowed in patterns. I'm guessing some
> confusion will arise from these two types of operators on where you can
> and/or should use them.

> Look at the tests and EEP for details and inspiration.

> A major difference from the EEP are variables in keys. Variables in keys are
> not allowed at all. This is because we want to reduce the scope for this
> first stage. Plenty to do besides that.

> Here are some additional disclaimers to make people sad.

> What is not implemented?

> - No variable keys.
> - No single value access.
> - No map comprehensions.
> - No datastructure to handle large Maps.
> - No MatchSpecs which uses the Maps syntax will work.

> Known issues

> - Dialyzer will not work with maps in the code, this include PLT building
> with erts and stdlib.
> - HiPE, the native compiler, will not with maps code.
> - EDoc will not work with maps.

> I'm sure there are other issues as well, it is a development branch after
> all. =)

> I would also like to point out that no optimizations are done either with
> respect to the generated code. This means that the instruction set may
> change. We know of several optimization we want to do before R17, especially
> for the match compiler so keep that in mind.

> We will continue stabilizing the Maps implementation as we move forward
> towards R17 and take appropriate action depending on the feedback you give
> us.

> I would like to continue with saying a few words about possible changes that
> we are thinking about.

> Variables in Keys

> This feature is actually furthest down on the work prio list. We want to
> stabilize the current features before moving forward and variable keys is
> the one most likely to be dropped if we get pressed for time. Meaning, it
> might not be implemented for R17 but instead implemented for R18. The plan
> right now is to keep it though.

> The External Format

> The current external format needs ordered keys as input for binary_to_term/1
> and in distribution.

> This is of course an inconvinience when dealing with other language
> interfaces which has no idea of what the erlang term order is. I instead
> propose that the external format should handle unordered input of key-value
> pairs. The trade off is a more complicated decoding which will take longer.

> The distribution format should also be extended to be able cache keys. This
> is similar to the atom cache except we
> cache the entire key array for maps. This has been the intention all along
> but it not mentioned in the EEP.

> Term order and sorting

> Finally the term order. This has been a sore point from the get go.

> Maps currently respects the Erlang term order for it's keys.

> The Erlang term order is what I call arithmetic term order. I propose that we
> extend Erlang with true term order where integer compares less then float,
> i.e. total term order.

> This would allowing newer ordered data structures, like maps, to be more
> useful. We don't have to take
> special care for the odd cases like keys 1.0 and 1 inhabiting the same slot
> in the data structure. gb_trees and such structures could also be extended
> to use this as those structures has the same limitations.

> With this type ordering we could have maps with this type of keys, #{ 1 =>
> "integer", 1.0 => "float" } without causing confusion.

> I've been told that ETS ordered sets tables used to have this behaviour.
> Distinguishing between floats and integers. This was supposedly before the
> open source era, way back when dinosaurs roamed the planet .. I'm not clear
> on the details on why this behaviour was removed. Probably because of
> inconsistencies.

> For maps to work with this I only need two things. First, a compare operation
> in the runtime that can distinguish between floats and integers, very easy.
> Secondly, a BIF that sort a list of terms with this new compare operation
> which will be used in the compiler.

> But for completness, the following operators should also be implemented:

> =:= term exact equal to, already implemented
> =/= term not equal to, already implemented
> =:< term less or equal than
> >:= term greater or equal than
> <:< term less than
> >:> term greater than

> So, true = 1 <:< 1.0.

> I don't know prolog but perhaps these sematics should mimic prolog to respect
> Erlangs heritage. I have no strong opinion on this.

> This syntax would mimic the already present =:= and =/= relational operators
> hower this syntax is another topic and should be a seperate EEP.

> Happy testing!

> 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/20131028/257a1cab/attachment.htm>