
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I just converted a ~5k lines of code project into using maps. I wrote myself mapfind(Key,Value,L) and mapstore(Key,Val,L,Map). That was all I needed. I did not care about compatibility with other types in list. <div><br><div>Is worrying about mixing tuples/records with maps in a list really necessary? In the 6+ years of writing erlang, I don’t think I’ve had a list of mixed types more than a couple of times. </div><div><div><br></div><div><br></div><div>Sergej</div><div><br><div><div>On 23 Nov 2014, at 15:43, Lukas Larsson <<a href="mailto:lukas@erlang.org">lukas@erlang.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hello,<div><br></div><div>I agree with you that in certain situations they would be very convenient. I've myself already written these functions in a couple of modules.</div><div><br></div><div>How do you imagine the semantics would work? It is fairly straight forward when the list only contains maps or tuples.</div><div><br></div><div>lists:keyfind(you, name, [#{ name => me, from => here }, #{ name => you, from => there}]) returns #{ name => you, from => there}.</div><div><br></div><div>But if we start to mix them some interesting corner cases pop up:</div><div><br></div><div>lists:keyfind(2, 1,[#{ 2 => 3 },{2, 4},#{ 1 => 2 } ]) returns {2,4} or #{ 1 => 2 }?</div><div>lists:keyfind(1, id, [{1,2}, #{ id => 2}, #{ id => 1}) returns #{ id => 1 } or crashes as id is not a valid key for {1,2}?</div><div><br></div><div>Or error cases of today:</div><div><br></div><div>lists:keyfind(2, id, []) today gives badarg, but should return false for a map list?</div><div><br></div><div>The safest way to introduce these functions would be to create new ones called something like lists:mkeyfind, but if possible it would be very neat to use the same API. It really is unfortunate that lists:keyfind is so forgiving today, you can mix and match whatever you want in the list and keyfind will quietly ignore it.</div><div><br></div><div>Also we have to consider which of the lists:key* functions we want a map counterpart? Does it make sense for all of them?</div><div><br></div><div>Thoughts? Ideas? Suggestions?</div><div><br></div><div>Lukas</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 22, 2014 at 7:33 PM, John Doe <span dir="ltr"><<a href="mailto:donpedrothird@gmail.com" target="_blank">donpedrothird@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It would be nice to extend lists module with a set of optimized functions like lists:key*** for lists containing maps. </div>

<br>_______________________________________________<br>

erlang-questions mailing list<br>

<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>

<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>

<br></blockquote></div><br></div>

_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></div></div></div></body></html>