On 1/29/2016 4:08 AM, Andrei Alexandrescu wrote:
> As has been discussed before there's been discussion about std.algorithm.reduce
> taking the "wrong" order of arguments (its definition predates UFCS). I recall
> the conclusion was there'd be subtle ambiguities if we worked reduce to
> implement both orders.
>
> So the next best solution is to introduce a new name such as the popular "fold",
> and put them together in the documentation.
>
>
> Thoughts?
>
> Andrei

Haskell can provide us with good inspiration and background for designing 'fold':

  https://wiki.haskell.org/Fold

Note there is a foldl, foldr, and some more obscure foldt, foldi, and some others.

Another design point is should fold be lazy? I.e.

    auto x = [1,2,3].fold!dg;

means that x is a function that will actually do the computation if called.

On Fri, 29 Jan 2016 07:08:01 -0500, Andrei Alexandrescu wrote:

> As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders.
> 
> So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation.
> 
> 
> Thoughts?
> 
> Andrei

For my own sake, I don't care at all. I've seen this announcement, I'll see deprecation warnings, so the change doesn't really bother me. A minor irritation that I'd have to change a couple lines of code, that's all.

I always call reduce with UFCS (same with almost everything in std.algorithm), so the parameter order doesn't affect me.

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
> As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders.
>
> So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation.
>
>
> Thoughts?
>
> Andrei

Yes, please.

On 1/29/2016 10:41 AM, Walter Bright wrote:
> Note there is a foldl, foldr, and some more obscure foldt, foldi, and some others.

foldr could be done with reverse.fold

On Fri, Jan 29, 2016 at 07:08:19PM +0000, deadalnix via Digitalmars-d wrote:
> On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
> >As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders.
> >
> >So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation.
> >
> >
> >Thoughts?
> >
> >Andrei
> 
> Yes, please.

Me Too(tm).


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.

On 01/29/2016 08:11 AM, Luís Marques wrote:
> On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
>> So the next best solution is to introduce a new name such as the
>> popular "fold", and put them together in the documentation.
>
> Just to bikeshed a little, I remember that when I first started using
> std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite
> often. D competes with C++ directly, so do consider that name :-)

Good point, thanks! -- Andrei

On 01/29/2016 08:56 AM, Dragos Carp wrote:
> On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
>> Just to bikeshed a little, I remember that when I first started using
>> std.algorithm I was ctrl-F'ing for "accumulate" and not finding it
>> quite often. D competes with C++ directly, so do consider that name :-)
>
> But not in python, where "accumulate"[1] is the generic equivalent of
> C++ "partial_sum"[2]. I like "fold" more.
>
> BTW this week, a colleague of mine implemented a python "accumulate" in
> D. Is there any interest to contribute it to Phobos? How should this be
> named?
>
> [1] https://docs.python.org/3/library/itertools.html#itertools.accumulate
> [2] http://en.cppreference.com/w/cpp/algorithm/partial_sum

That'd be interesting if (a) lazy and (b) general a la https://dlang.org/library/std/range/recurrence.html. -- Andrei

On 1/29/2016 12:36 PM, Andrei Alexandrescu wrote:
> On 01/29/2016 08:11 AM, Luís Marques wrote:
>> Just to bikeshed a little, I remember that when I first started using
>> std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite
>> often. D competes with C++ directly, so do consider that name :-)
>
> Good point, thanks! -- Andrei

Given the different names for this used in different languages, I suggest in the documentation for 'fold' having an 'Also Known As' section, which will make it greppable.

On Friday, 29 January 2016 at 18:41:46 UTC, Walter Bright wrote:
> Haskell can provide us with good inspiration and background for designing 'fold':
>
>   https://wiki.haskell.org/Fold
>
> Note there is a foldl, foldr, and some more obscure foldt, foldi, and some others.

Once you use names like foldl and foldr, you're headed down the slippery slope to Common Lisp naming. Please at least use foldLeft and foldRight if you want to go that route.

On 1/29/2016 5:11 AM, Luís Marques wrote:
> Just to bikeshed a little, I remember that when I first started using
> std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often.
> D competes with C++ directly, so do consider that name :-)

For algorithms and FP in general, we may be better off drawing inspiration from Haskell, as C++ does not have FP in its DNA.