<div dir="auto">I agree with Dmitry - if the pattern is common enough then a new module for dealing with such structures seems like the best way forward. Invisible to those that don't need it but available and performant to those that do.<div dir="auto"><br></div><div dir="auto">Karl</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 24 Sep 2019, 15:11 Dmitry Belyaev, <<a href="mailto:be.dmitry@gmail.com">be.dmitry@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If it's all about lists, you've got all you need: lists:search/2 or as previously mentioned lists:dropwhile.<br><br>To me presence of lists:key... functions is a serious legacy which is justified only because there are tons of code using it. I'm glad we don't have all of the 'sofs' functions in 'lists' module.<br>Of course it would be nice to have faster versions than handcrafted functions, but I'd like them to be introduced in a separate module, e.g. list_of_maps.<br><br><div class="gmail_quote">On 24 September 2019 3:32:55 pm AEST, Vance Shipley <<a href="mailto:vances@motivity.ca" target="_blank" rel="noreferrer">vances@motivity.ca</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre>On Tue, Sep 24, 2019 at 10:48 AM Richard O'Keefe <<a href="mailto:raoknz@gmail.com" target="_blank" rel="noreferrer">raoknz@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex">I would argue that the focus of these functions is the maps, not the lists they happen to be inside.<br></blockquote><br>In my mind this is all about lists. Think small maps and big lists.<br>That the terms are maps is a detail I have to deal with in processing<br>my lists. I just want the lists module to be orthogonal. If we aren't<br>going to move all the lists:key* functions to a 'records' module<br>(please don't) let's simply add support for the new term type which<br>"replaces" records.<br><br>Your example is certainly all about maps but it doesn't help my use cases.<br><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex">Perhaps the whole thing is inside out.  Perhaps what's really needed<br>is something that says<br> - here is a list of maps and a key<br> - give me a map of lists and a list<br> If {M,R} = maps:transpose(Ms, K)<br> then R is the filter of Ms by the condition "does not have key K"<br> and M is a map from V to the filter of Ms by the condition "has V as<br>value for key K".<br>Only do the linear scan once.<br></blockquote><br></pre></blockquote></div><br>-- <br>Kind regards,<br>Dmitry Belyaev</div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank" rel="noreferrer">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>