[erlang-questions] Maps branch and disclaimers

[Robert Virding]

"Not me against". 

But I think that term_compare/2 should return the term comparison operators <:<, =:=, >:> (or the @... alternatives) while compare/2 should return the old comparison operators as this is what they test. 

Robert 

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

> From: "Thomas Lindgren" <thomasl_erlang@REDACTED>
> To: "Björn-Egil Dahlberg" <wallentin.dahlberg@REDACTED>, "Robert Virding"
> <robert.virding@REDACTED>
> Cc: "Erlang" <erlang-questions@REDACTED>
> Sent: Monday, 28 October, 2013 10:48:17 PM
> Subject: Re: [erlang-questions] Maps branch and disclaimers

> How about adding this:

> term_compare(X,Y) -> '<' | '==' | '>'.

> Usage:

> case term_compare(X, Y) of
> '==' -> ...;
> ...
> end

> In that case, compare(X,Y) could be useful too.

> Best,
> Thomas

> On Monday, October 28, 2013 8:07 PM, Björn-Egil Dahlberg
> <wallentin.dahlberg@REDACTED> wrote:

> > 2013/10/28 Robert Virding < robert.virding@REDACTED >
> 

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

> > Great! =)
> 

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

> > I agree with your point. Ease of conversion would be great. But, why would
> > dict be more suitable than gb_trees ? The current API is of personal
> > preference ofc.
> 

> > > - 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'm thinking of writing another EEP. I did a test implementation of <:<,
> > >:>,
> > =:<, >:= this weekend to see how it would pan out. See,
> > https://github.com/psyeugenic/otp/commits/egil/total-order-relops for
> > details. Seemed ok. The syntax can be changed to suite prolog heritage but
> > the @... syntax freak me out to be honest =)
> 

> > Also what should we do with =:= vs @== and =/= vs @/= in that case? Should
> > we
> > have two operators with the same meaning?
> 

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

> > Check.
> 

> > > - 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.
> > 
> 

> > There are currently no generator implemented, and it might not be
> > implemented
> > either. Also, I think K := V <- Map works for the visual and it is
> > definitely unique enough to be parsable. The difference of #{ K := V } <-
> > List vs. K := V <- Map might be to subtle though. I think we might have to
> > revisit this and give maps its own arrow.
> 

> > Thank you!
> 

> > //Björn-Egil
> 

> > > Robert
> > 
> 

> > > > 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
> > > 
> > 
> 

> > > _______________________________________________
> > 
> 
> > > erlang-questions mailing list
> > 
> 
> > > erlang-questions@REDACTED
> > 
> 
> > > http://erlang.org/mailman/listinfo/erlang-questions
> > 
> 

> > _______________________________________________
> 
> > 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/20131029/826bd160/attachment.htm>