[m-dev.] for review: aggregate/4

[Fergus Henderson]

Thomas Charles CONWAY, you wrote:
> 
> > Given that there is no efficiency advantage, aggregate/4 doesn't
> > really buy you much over just calling solutions/2 and list__foldl/4.
> > Is it really worth adding to the library?
> 
> Orthogonality.

OK, I'll buy that one.

> Here is a revised diff which I have comitted - the change to the more
> efficient implementation can come later as an enhancement.

That diff looks fine, except that you have mixed spaces and tabs:

> +        % aggregate/4 generates all the solutions to a predicate,
> +	% sorts them and removes duplicates, then applies an accumulator
> +	% predicate to each solution in turn:
> +        %
> +        % aggregate(Generator, Accumulator, Acc0, Acc) <=>
> +        %       solutions(Generator, Solutions),
> +        %       list__foldl(Accumulator, Solutions, Acc0, Acc).
> +	%
...
> +        % unsorted_aggregate/4 generates all the solutions to a predicate
> +        % and applies an accumulator predicate to each solution in turn:
> +        %
> +        % unsorted_aggregate(Generator, Accumulator, Acc0, Acc) <=>
> +        %       unsorted_solutions(Generator, Solutions),
> +        %       list__foldl(Accumulator, Solutions, Acc0, Acc).
> +	%
> +	% The current implementation is in terms of [unsorted_]solutions and
> +	% list__foldl, which, for a predicate with N solutions requires O(N)
> +	% memory, whereas it is possible to implement unsorted_aggregate
> +	% to use O(1) memory.

Once you've fixed that, go ahead and commit it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.