[m-rev.] for pre-review: one_or_more.m and one_or_more_map.m

[Julien Fischer]

Hi Zoltan,

On Mon, 30 Dec 2019, Zoltan Somogyi wrote:

> I have now written a first draft of the one_or_more.m and one_or_more_map.m
> modules we sort-of discussed over the last day. I would like feedback on whether
> they contain the right functionality, so I am sending this partial diff. Since the diff
> removes the one_or_more type from list.m, a full diff would require changes to
> all the compiler modules that used that type, and there are a lot of them. However,
> that would also cause huge conflicts with the big change I am working on that
> motivated the new modules in the first place. So I am proposing to commit
> this diff not on its own, but as part of that later, big diff. (Right now, that full diff
> touches 88 files and contains 25k+ lines.)
>
> My two main questions are:
>
> - Which, if any, of the currently-commented-out parts of one_or_more.m, which
>  now contain just code copied from list.m, be adapted to one_or_mores and
>  included in the module, and which should just be deleted as inapplicable
>  or unneeded with one_or_mores.

I think its fine to leave out all the ones you've commented out with ZZZ
comments.

> - What predicates in one_or_more.m should have their outputs compared to the
>  outputs of the corresponding list.m predicates on the same data. Some are
>  too simple to need testing, while some definitely need it; help me draw the line
>  between them.

Well, definitely

    member_index0
    all the index* predicates
    all the search* and lookup* predicates
    all the replace* predicates
    *very* defintely anything related to merging or sorting
    all the split* predicates
    find_first_match
    any filtering predicates

One thing I would note in the diff:

> diff --git a/library/one_or_more.m b/library/one_or_more.m
> index e69de29bb..c17356df8 100644
> --- a/library/one_or_more.m
> +++ b/library/one_or_more.m
> @@ -0,0 +1,2745 @@
> +%---------------------------------------------------------------------------%

...

> +:- func one_or_more_to_list(one_or_more(T)) = list(T).
> +:- mode one_or_more_to_list(di) = uo is det.
> +:- mode one_or_more_to_list(in) = out is det.
> +
> +:- pred list_to_one_or_more(list(T)::in, one_or_more(T)::out) is semidet.
> +:- pred list_to_one_or_more_det(list(T)::in, one_or_more(T)::out) is det.


The usual convention is for "det_" to be the prefix. I don't see any reason
to depart from that convention here.

Julien.