[m-rev.] for post-commit review: begin addressing issues in the ranges module

[Julien Fischer]

On Mon, 6 Jan 2025 at 16:43, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> On Mon, 6 Jan 2025 15:22:26 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > > Of course, list.member does it, but it came from Prolog.
> > > I would prefer it if the new predicates, nondet_member and
> > > nondet_range_member, had the ranges arg before the int arg or args.
> >
> > nondet_member is *not* a new predicate. Altering its argument ordering will be
> > a breaking change.
>
> I missed that.
>
> > I'm not opposed to doing so, although I will need to take a
> > look at how extensively it is currently being used beforehand.
>
> In that case, what we should probably do is introduce a new
> predicate with the in, out order, and mark the old predicate obsolete
> in its favor. The new one should have a more descriptive name than
> "nondet_member". Would "return_members" or "return_members_one_by_one"
> do?

I have a preference for nondet predicates like these having "nondet" somewhere
in their names.  Obviously, it makes no difference to the compiler but
it does help
to make it obvious to the programmer where calls that introduce choice
points are.

I've had a look through G12 (and some other Opturion projects) and
there are very
few calls to either of these predicates.  I can't speak for other
users, but I think we
can probably get away with making a breaking change here.

> > We should probably look at adding something like nondet_member to all the set
> > modules as a synonym for the '(out, in) is nondet' mode of member (provided
> > the argument re-ordering goes ahead.)
>
> Once we settled on what we should do for ranges.m, yes.
>
> > > Also, nondet_range_member is ambiguous. It could, and does, mean
> > > "returns each range in a set of ranges", but it could also be read as
> > > "return each *int* in a range". The signature rules that out, but
> > > it would be nice if we had a name that has no such ambiguity. Unfortunately,
> > > I can't think of one right now.
> >
> > The usual convention in this module is that predicates with "range" in their
> > name operate on ranges (e.g. range_foldl) and those without it operate on
> > individual values in the set.
>
> Is that documented anywhere? If not, it should be.

I will add some documentation  for it.

Julien.