[m-rev.] for review: add array.all_{true,false}.2

[Julien Fischer]

On Mon, Jul 22, 2013 at 12:43 PM, Paul Bone <paul at bone.id.au> wrote:

> On Mon, Jul 22, 2013 at 12:04:59PM +1000, Julien Fischer wrote:
> >
> > Hi Paul,
> >
> > On Mon, 22 Jul 2013, Paul Bone wrote:
> >
> >>> @@ -2612,6 +2636,40 @@ array.map_corresponding_foldl_2(P, I, N, A, B,
> !C, !D) :-
> >>>      ).
> >>>
> >>> +
> >>> +array.all_false(Pred, Array) :-
> >>> +    do_all_false(Pred, array.min(Array), array.max(Array), Array).
> >>> +
> >>> +:- pred do_all_false(pred(T), int, int, array(T)).
> >>> +%:- mode do_all_false(in(pred(in) is semidet), in, in, array_ui) is
> semidet.
> >>> +:- mode do_all_false(in(pred(in) is semidet), in, in, in) is semidet.
> >>> +
> >>> +do_all_false(Pred, I, UB, Array) :-
> >>> +    ( if I =< UB then
> >>> +        Elem = Array ^ unsafe_elem(I),
> >>> +        not Pred(Elem),
> >>> +        do_all_false(Pred, I + 1, UB, Array)
> >>> +    else
> >>> +        true
> >>> +    ).
> >>> +
> >>
> >> maybe I'm bikeshedding here.  But would it not be better to implement
> >> all_false in terms of all true by adding a closure?
> >
> > Better in what way?  (It is certainly more expensive which is probably
> > why we *don't* do that for list.all_false/2.)
>
> It avoids repitition.


The repetition is not significant in this case, and in any case, we should
try
to avoid obvious inefficiencies in library code.


> But I don't know if the compiler will be able to
> specalize the higher order call and then inline it.


With the right optimization settings I think it should be able to.
(OTOH, I'd prefer not to rely on having the right optimization settings in
the
first place.)

Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20130722/66239d9f/attachment.html>