Tue Aug 22 03:23:47 CEST 2017
On Tue, Aug 22, 2017 at 01:13:12PM +1200, Richard A. O'Keefe wrote:
> On 21/08/17 7:30 PM, Roger Lipscombe wrote:
> >On 20 August 2017 at 23:46, Richard A. O'Keefe <> wrote:
> >> (1) lists: is absolutely the wrong place for them.
> >The thing I missed at first is this:
> >In Lukas's suggestion, these are *list of maps*, and we're searching
> >the *list* for the *map* with the specified K/V pair. If we're dealing
> >with *lists* (of maps), then the 'lists' module is, at first glance, a
> >reasonable place to put this functionality.
> The problem is that lists are such a general-purpose data structure.
> Suppose we had an analogue of select(2) that took a list of io devices
> and returned one of them that was ready, would we put that in the
> lists: module or would we expect it to be in io:?
This one is easy: `io' module, because the primary focus is not
data structure manipulation, but reading or writing.
Actually, I initially thought the mapfind() function to be more like
map() + find() (a.k.a. filter()). It's not uncommon for me to want to
combine map() and some other operation. I treat lists:keyfind() as
a function that would normally belonged to proplists module, except that
it's mainly intended for 3+ tuples.
[select(2) analogue that works with lists]
> For me, the important thing is not whether the elements are
> held in a list or a tuple or a set or whatever but what are
> the focal things we're acting on.
> Of course, this is arguably an instance of the expression problem,
> and such there may be no best answer.
Well, at least two people agree on what to expect in this case.
More information about the erlang-questions