[erlang-questions] lists:mapfind?

[Michael Truog]

On 08/21/2017 06:13 PM, 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 <ok@REDACTED> 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:?
>
> 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.
>

I agree that these functions should not be added to the lists module, since it already has many functions that do not need to be confused with newer additions (new functions confused with lists:keymap/3, lists:map/2, lists:mapfoldl/3, lists:mapfoldr/3, simply due to the word "map" that doesn't relate to map elements). I understand the lists module already has functions for handling lists that contain tuples with the "key" functions.

In my mind, this argues for adding the concept of a namespace to Erlang source code, so that ".map:" or ".maps:" can be used as a suffix on lists, to show that the functions relate to lists that contain maps.  I understand the past concept of Erlang packages failed and was gradually removed.  Also, I understand there is the common response that you can always put periods in module names, similar to how elixir modules have an "Elixir." module name prefix for beam output.  The current situation is unable to easily manage complexity as the SLOC of Erlang source code grows, artificially limiting the size of Erlang codebases, and the dependencies they may be able to manage (with the additional problem of being unable to utilize more than 1 version of the same dependency).  I believe this hesitation to add more complexity to the single "lists" module is evidence of a problem, and the need for more hierarchical organization of source code, even if it only results in periods in 
module names.

Best Regards,
Michael