<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>"Not me against".<br></div><div><br></div><div>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.<br></div><div><br></div><div>Robert<br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Thomas Lindgren" <thomasl_erlang@yahoo.com><br><b>To: </b>"Björn-Egil Dahlberg" <wallentin.dahlberg@gmail.com>, "Robert Virding" <robert.virding@erlang-solutions.com><br><b>Cc: </b>"Erlang" <erlang-questions@erlang.org><br><b>Sent: </b>Monday, 28 October, 2013 10:48:17 PM<br><b>Subject: </b>Re: [erlang-questions] Maps branch and disclaimers<br><div><br></div><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:12pt" data-mce-style="color: #000; background-color: #fff; font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 12pt;"><div>How about adding this:</div><div><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">term_compare(X,Y) -> '<' | '==' | '>'.</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">Usage:</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue',
 Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue',
 Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">case term_compare(X, Y) of</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">  '==' -> ...;</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">  ...</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style:
 normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">end</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">In that case, compare(X,Y) could be useful too. </div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"><br></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">Best,</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,
 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue,
 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;">Thomas</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;" data-mce-style="color: #000000; font-size: 16px; font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-color: transparent; font-style: normal;"> </div><div class="yahoo_quoted" style="display: block;" data-mce-style="display: block;"><br> <br><div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;" data-mce-style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"><div style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;" data-mce-style="font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 12pt;"><div dir="ltr"><span style="font-family: Arial; font-size: small;" data-mce-style="font-family: Arial; font-size: small;" face="Arial" size="2"> On Monday, October 28, 2013 8:07 PM, Björn-Egil Dahlberg <wallentin.dahlberg@gmail.com> wrote:<br> </span></div><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;" data-mce-style="border-left: 2px solid #1010ff; margin-left: 5px; margin-top: 5px; padding-left: 5px;"><div class="y_msg_container"><div id="yiv4180816397"><div><div dir="ltr">2013/10/28 Robert Virding <span dir="ltr"><<a rel="nofollow" shape="rect" target="_blank" href="mailto:robert.virding@erlang-solutions.com" data-mce-href="mailto:robert.virding@erlang-solutions.com">robert.virding@erlang-solutions.com</a>></span><br clear="none"><div class="yiv4180816397gmail_extra"><div class="yiv4180816397gmail_quote"><blockquote class="yiv4180816397gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;" data-mce-style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;"><div>Great! But I do have some comments (of course):<br clear="none"></div></div></div></blockquote><div><br clear="none"></div><div>Great! =)</div><div> </div><blockquote class="yiv4180816397gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;" data-mce-style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;"><div><br></div><div><br clear="none"></div><div>- I would keep the function names from the dict module where possible. This to make it easier to convert.<br clear="none"></div></div></div></blockquote><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div> </div><blockquote class="yiv4180816397gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;" data-mce-style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;"><div><br></div><div><br clear="none"></div><div>- 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.<br clear="none"></div></div></div></blockquote><div><br clear="none"></div><div>I'm thinking of writing another EEP. I did a test implementation of <:<, >:>, =:<, >:= this weekend to see how it would pan out. See, <a rel="nofollow" shape="rect" target="_blank" href="https://github.com/psyeugenic/otp/commits/egil/total-order-relops" data-mce-href="https://github.com/psyeugenic/otp/commits/egil/total-order-relops">https://github.com/psyeugenic/otp/commits/egil/total-order-relops</a> for details. Seemed ok. The syntax can be changed to suite prolog heritage but the @... syntax freak me out to be honest =)</div><div><br clear="none"></div><div>Also what should we do with =:= vs @== and =/= vs @/= in that case? Should we have two operators with the same meaning?</div><div> </div><blockquote class="yiv4180816397gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;" data-mce-style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;"><div><br></div><div><br clear="none"></div><div>- I also definitely agree to keep the syntactic footprint to a minimum and introduce as little new syntax as possible.<br clear="none"></div></div></div></blockquote><div><br clear="none"></div><div>Check.</div><div> </div><blockquote class="yiv4180816397gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;" data-mce-style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;"><div><br></div><div><br clear="none"></div><div>- 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.<br clear="none"></div></div></div></blockquote><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div><br clear="none"></div><div>Thank you!</div><div><br clear="none"></div><div>//Björn-Egil</div><div class="yiv4180816397yqt6741439792" id="yiv4180816397yqtfd63232"><div> </div><blockquote class="yiv4180816397gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;" data-mce-style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif;"><div><br></div><div><br clear="none"></div><div>Robert<br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><hr><blockquote style="padding-left: 5px; font-size: 12pt; font-style: normal; margin-left: 5px; font-family: Helvetica, Arial, sans-serif; text-decoration: none; font-weight: normal; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255);" data-mce-style="padding-left: 5px; font-size: 12pt; font-style: normal; margin-left: 5px; font-family: Helvetica, Arial, sans-serif; text-decoration: none; font-weight: normal; border-left-width: 2px; border-left-style: solid; border-left-color: #1010ff;"><b>From: </b>"Björn-Egil Dahlberg" <<a rel="nofollow" shape="rect" target="_blank" href="mailto:egil@erlang.org" data-mce-href="mailto:egil@erlang.org">egil@erlang.org</a>><div><div class="yiv4180816397h5"><br clear="none"><div><br clear="none"></div>Hi!<br clear="none"> <br clear="none"> Here you go, Maps!<br clear="none"> <br clear="none"> I've pushed a Maps branch to Erlang/OTPs repository at GitHub.<br clear="none"> <br clear="none"> To get the branch,<br clear="none"> <br clear="none"> <tt>  git fetch <a rel="nofollow" shape="rect" target="_blank" href="mailto:git@github.com:erlang/otp.git" data-mce-href="mailto:git@github.com:erlang/otp.git">git@github.com:erlang/otp.git</a> egil/maps/eep-implementation</tt><br clear="none"> <br clear="none"> or find it at <a rel="nofollow" shape="rect" target="_blank" href="https://github.com/erlang/otp/tree/egil/maps/eep-implementation" data-mce-href="https://github.com/erlang/otp/tree/egil/maps/eep-implementation">https://github.com/erlang/otp/tree/egil/maps/eep-implementation</a><br clear="none"> <br clear="none"> I want to state the following so there is no room for uncertainty:<br clear="none"> - This branch contains a <b>development stage</b> of the <b>experimental</b> Maps feature for Erlang.<br clear="none"> <br clear="none"> This means:<br clear="none">  - Do not use it in production since it is not stable,<br clear="none">  - Do not base any git branch on this branch since it will most likely be rebased,<br clear="none">  - and finally, we reserve the right to change any API or interfaces to Maps currently implemented.<br clear="none"> <br clear="none"> The implementation is based on EEP 43 - Maps, see <a rel="nofollow" shape="rect" target="_blank" href="http://github.com/erlang/eep/blob/master/eeps/eep-0043.md" data-mce-href="http://github.com/erlang/eep/blob/master/eeps/eep-0043.md">http://github.com/erlang/eep/blob/master/eeps/eep-0043.md</a>, for details.<br clear="none"> <br clear="none"> <span style="text-decoration:underline;" data-mce-style="text-decoration: underline;">What is implemented?</span><br clear="none"> <br clear="none"> 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 ==.<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> I recommend people look at the EEP for information and also the testsuite located at <tt>erts/emulator/test/map_SUITE.erl</tt> for information on how to use Maps since no other documentation is available.<br clear="none"> <br clear="none"> Roughly, <br clear="none"> <tt>  </tt><tt>M0 = #{ key => Value1, "key" => Value2}, % for construction.</tt><tt><br clear="none"> </tt><tt>  M1 = M1#{  "key" := Value3, <<"key">> => Value4 }, % for updates</tt><tt><br clear="none"> </tt><tt>  #{ "key" := V } = M1. % for matching</tt><tt><br clear="none"> </tt><br clear="none"> 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.<br clear="none"> <br clear="none"> Look at the tests and EEP for details and inspiration.<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> Here are some additional disclaimers to make people sad.<br clear="none"> <br clear="none"> <span style="text-decoration:underline;" data-mce-style="text-decoration: underline;">What is not implemented?</span><br clear="none"> <br clear="none"> - No variable keys.<br clear="none"> - No single value access.<br clear="none"> - No map comprehensions.<br clear="none"> - No datastructure to handle large Maps.<br clear="none"> - No MatchSpecs which uses the Maps syntax will work.<br clear="none"> <br clear="none"> <span style="text-decoration:underline;" data-mce-style="text-decoration: underline;">Known issues</span><br clear="none"> <br clear="none"> - Dialyzer will not work with maps in the code, this include PLT building with erts and stdlib.<br clear="none"> - HiPE, the native compiler, will not with maps code.<br clear="none"> - EDoc will not work with maps.<br clear="none"> <br clear="none"> I'm sure there are other issues as well, it is a development branch after all. =)<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> We will continue stabilizing the Maps implementation as we move forward towards R17 and take appropriate action depending on the feedback you give us.<br clear="none"> <br clear="none"> I would like to continue with saying a few words about possible changes that we are thinking about.<br clear="none"> <br clear="none"> <span style="text-decoration:underline;" data-mce-style="text-decoration: underline;">Variables in Keys</span><br clear="none"> <br clear="none"> 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. <br clear="none"> <br clear="none"> <span style="text-decoration:underline;" data-mce-style="text-decoration: underline;">The External Format</span><br clear="none"> <br clear="none"> The current external format <i>needs</i> ordered keys as input for binary_to_term/1 and in distribution.<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> The distribution format should also be extended to be able cache keys. This is similar to the atom cache except we<br clear="none"> cache the entire key array for maps. This has been the intention all along but it not mentioned in the EEP.<br clear="none"> <br clear="none"> <span style="text-decoration:underline;" data-mce-style="text-decoration: underline;">Term order and sorting</span><br clear="none"> <br clear="none"> Finally the term order. This has been a sore point from the get go.<br clear="none"> <br clear="none"> Maps currently respects the Erlang term order for it's keys.<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> This would allowing newer ordered data structures, like maps, to be more useful. We don't have to take<br clear="none"> 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.<br clear="none"> <br clear="none"> With this type ordering we could have maps with this type of keys, #{ 1 => "integer", 1.0 => "float" } without causing confusion.<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> 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.<br clear="none"> <br clear="none"> But for completness, the following operators should also be implemented:<br clear="none"> <br clear="none">     =:=         term exact equal to, already implemented<br clear="none">     =/=         term not equal to, already implemented<br clear="none">     =:<         term less or equal than<br clear="none">     >:=         term greater or equal than<br clear="none">     <:<         term less than<br clear="none">     >:>         term greater than<br clear="none"> <br clear="none"> So, true = 1 <:< 1.0.<br clear="none"> <br clear="none"> I don't know prolog but perhaps these sematics should mimic prolog to respect Erlangs heritage. I have no strong opinion on this.<br clear="none"> <br clear="none"> This syntax would mimic the already present =:= and =/= relational operators hower this syntax is another topic and should be a seperate EEP.<br clear="none"> <br clear="none"> Happy testing!<br clear="none"> <br clear="none"> Regards,<br clear="none"> Björn-Egil Dahlberg<br clear="none"> Erlang/OTP<br clear="none"> <br clear="none"></div></div><div class="yiv4180816397im">_______________________________________________<br clear="none">erlang-questions mailing list<br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="mailto:erlang-questions@erlang.org" data-mce-href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="http://erlang.org/mailman/listinfo/erlang-questions" data-mce-href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none"></div></blockquote><div><br clear="none"></div></div></div><br clear="none">_______________________________________________<br clear="none"> erlang-questions mailing list<br clear="none"> <a rel="nofollow" shape="rect" target="_blank" href="mailto:erlang-questions@erlang.org" data-mce-href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"> <a rel="nofollow" shape="rect" target="_blank" href="http://erlang.org/mailman/listinfo/erlang-questions" data-mce-href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none"> <br clear="none"></blockquote></div></div><div class="yiv4180816397yqt6741439792" id="yiv4180816397yqtfd63009"><br clear="none"></div></div></div></div></div><br><div class="yqt6741439792" id="yqtfd02310">_______________________________________________<br clear="none">erlang-questions mailing list<br clear="none"><a shape="rect" href="mailto:erlang-questions@erlang.org" target="_blank" data-mce-href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank" data-mce-href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none"></div><br><div><br></div></div></blockquote></div></div></div></div></blockquote><div><br></div></div></body></html>