Why, for example, maps but array?

[zxq9]

On 2021/08/15 7:42, Lloyd R. Prentice wrote:
> I just used sets today to write a search tag generator. Works. But it surprises me that obvious functions like file:move/2 and the a write companion to file:consult/1 are not in the library. No doubt someone has an explanation.

Indeed! https://zxq9.com/archives/1021

> Re if constructions, I turn first to pattern matching, next to case statements. But I suspect there’s a cogent discussion buried in the Erlang archives.

There is and I've written about it a bit but have no idea where it is in 
the archives -- search engines are not finding it.

>> On Aug 14, 2021, at 6:27 PM, Michael P. <empro2@REDACTED> wrote:
>> I cannot imagine that anyone applies the
>> general concept of 'module deals with lists'
>> to writing a concrete line of source code.
>>
>> To me `+` is 'addition', not 'additions'.

There is something to this...

>> The decision seems to depend on author
>> and some tossing of coins.

...and this as well.

There are few different things going on.

One layer is the semantic choice of "does the name of this module 
indicate that this modules 'deals with Xs' or does it represent *a* 
single X when the user is typing it?"

Another layer is the tradition of functional languages having lots of 
listy and collectiony data structures and writing functions and modules 
to do things over them as collections instead of individual elements.

I like it when the naming semantic for the interface module to an X is 
singular. It makes sense to me as a user of that module to say 
`map:find(Key, Map)` rather than `maps:find(Key, Map)`, but also makes 
sense to have a separate module called actually `maps` for things like 
the "List of Maps" module that I wrote a while back that was recently 
discussed as a possible candidate for inclusion in the stdlib (though 
probably under a different name). https://gitlab.com/zxq9/lom

These semantic sort of things are quirks and no guideline for 
formalizing them has been fleshed out. Argument order regularity is also 
a bit of a crap shoot throughout the stdlib, but over time you sort of 
learn it and stop caring.

Fixing this stuff up would be cool, but takes a huge amount of effort 
that is a bit hard to muster for such a small community with zero funding.

-Craig