[m-dev.] Fwd: Re: multi_map and one_or_more

[Zoltan Somogyi]

I accidentally sent this reply only to Julien, instead of the whole list.

Zoltan.

----- Start Forwarded Message -----
Sent: Sun, 29 Dec 2019 01:56:58 +1100 (AEDT)
From: "Zoltan Somogyi" <zoltan.somogyi at runbox.com>
To: "Julien Fischer" <jfischer at opturion.com>
Subject: Re: [m-dev.] multi_map and one_or_more



On Sun, 29 Dec 2019 01:45:08 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> Does your change add additional operations on multi_maps, or just use
> them?

Just uses them. No new ops, at least not yet.

> > - Second, I would like to add a new module to the standard library that
> >   is a version of multi_map but with the range type being one-or-more.
> 
> I guess in the absence of an abstraction barrier in the multi_map module
> we cannot just make the mode of arguments returning a list of values be
> out(non_empty_list).

Another reason for that is the fact that an output list of a predicate is
guaranteed to be nonempty is not a property of that predicate alone,
but an invariant that has to be cooperatively maintained by all the ops
on the data structure. A type such as one_or_more can enforce this;
a mode on some operations cannot.

> > I have some questions for you guys about this.
> >
> > - 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.
> 
> The major downside being that it will further inflate the already large
> interface of the list module.

Yes, though the increase in conceptual complexity is significantly less
than the increase in line count.

> >  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 third option would be to make the one_or_more module a submodule of
> the list module.

I don't particularly like that option, unless we are consistent enough to make
all the set_*.m modules submodules of set.m, and multi_map.m a submodule
of map.m.

> > - 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.
> 
> I prefer one_or_more_map.  (Actually, what I prefer is that the name
> of the one_or_more module and the associated map type align.)

We could name both the module and the type one_or_more_map, and add
oom_map as a type equivalence, killing two birds with one stone.

> Another alternative would be to "fix" the existing multi_map module.  Of
> course, that's likely to break a good deal of existing code.

Yes, it would, and I want to avoid that, because the required user fixes,
while not difficult, are not as trivial as applying a global renaming substitution
either.

Once we have a one_or_more_map.m module, we can encourage people
to move from multi_map to it at their own pace.

Zoltan.


----- End Forwarded Message -----

Zoltan.