[m-dev.] multi_map and one_or_more

[Peter Wang]

On Sun, 29 Dec 2019 00:12:36 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> - Should the operations on one_or_mores go into list.m, or into a new module?
>   I can see arguments on both sides, but favour the former slightly, for two
>   reasons: because it would make it much harder to forget to add an
>   one_or_more version of a newly added operation on lists, and because
>   it would continually remind people using the module's documentation
>   about the availability of the one_or_more version.
> 
>   However, I would be ok with putting the new operations into a new module.
>   The new module should also contain the one_or_more type itself, and its
>   existing operations, so this wouldn't be backward compatible with older ROTDs,
>   though it would be compatible with the last release. The obvious module name
>   is one_or_more.m.

A new module makes more sense to me.

Moving the type should not break much code outside of the compiler,
based on a quick scan of the code I have at hand and Github code search.

> 
> - With the same-module approach, what naming scheme should we follow
>   to differentiate operations on one_or_mores from operations on lists?
>   The possibilities include "one_or_more_" and the shorter but obviously
>   less expressive version "oom_" as prefixes. (If the one_or_more operations
>   are in their own module, then the module name is the obvious disambigation.)
> 
> - What should the one_or_more equivalent of multi_map be named?
>   I think we need to choose either a short name or an expressive name;
>   I don't there is a name that is both. I lean slightly towards oom_map,
>   but one_or_more_map and multi_map_oom are also possibilities.
> 

"oom" is a common abbreviation for "out-of-memory" so avoiding that
overload is preferable. one_or_more_map sounds okay.

> - Should the new version of multi_map have its own module? Here the
>   tradeoffs are different, since multi_map is already a mutatis-mutandis
>   copy of map.m. This allows multi_map.m to use the same predicate
>   and function names as map.m, and this should also be true for the new
>   (e.g.) oom_map.m.

Yes, new module.

Peter