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

Definitely yes.

Atila

On 2/2/16 11:02 AM, Atila Neves 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
>
> Definitely yes.

Atila, wanna do the honors? -- Andrei

On 1/30/16 1:08 PM, David Nadlinger wrote:
> On Saturday, 30 January 2016 at 17:40:38 UTC, Andrei Alexandrescu wrote:
>> I forgot the distinction between currying and partial application. Can
>> we also define currying in current D? -- Andrei
>
> Currying is turning (A, B, C) -> D into A -> (B -> (C -> D)), i.e. a
> function with multiple arguments into a sequence of functions that each
> take a single argument to apply each.
>
> I think I've implemented something like that for fun once, but never
> really found much use for it. In the few places where I could have used
> it (mostly binary functions), just using a lambda and partial
> application seemed to be much more idiomatic. I guess D lacks any idioms
> that would make its use come naturally.
>
>   - David

Thanks. I guess it'd be nice to have it on code.dlang.org somewhere so people can play with it. -- Andrei

On Tuesday, 2 February 2016 at 20:02:39 UTC, Andrei Alexandrescu wrote:
> On 2/2/16 11:02 AM, Atila Neves 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
>>
>> Definitely yes.
>
> Atila, wanna do the honors? -- Andrei

If it's not urgent, sure.

Atila

On 2/2/16 3:50 PM, Atila Neves wrote:
> On Tuesday, 2 February 2016 at 20:02:39 UTC, Andrei Alexandrescu wrote:
>> On 2/2/16 11:02 AM, Atila Neves 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
>>>
>>> Definitely yes.
>>
>> Atila, wanna do the honors? -- Andrei
>
> If it's not urgent, sure.

Thanks! And don't forget: in D, everything is top priority. -- Andrei

On Wednesday, 3 February 2016 at 00:57:18 UTC, Andrei Alexandrescu wrote:
> On 2/2/16 3:50 PM, Atila Neves wrote:
>> On Tuesday, 2 February 2016 at 20:02:39 UTC, Andrei Alexandrescu wrote:
>>> On 2/2/16 11:02 AM, Atila Neves 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
>>>>
>>>> Definitely yes.
>>>
>>> Atila, wanna do the honors? -- Andrei
>>
>> If it's not urgent, sure.
>
> Thanks! And don't forget: in D, everything is top priority. -- Andrei

Of course it is ;)

I guess this is to be a brand new PR? I've been reading the old one and the discussions. A lot of unanswered questions there and I have a new opinion on at least one of them.

Atila

On 02/01/2016 03:46 AM, Dragos Carp wrote:
> On Friday, 29 January 2016 at 20:40:18 UTC, Andrei Alexandrescu wrote:
>> That'd be interesting if (a) lazy and (b) general a la
>> https://dlang.org/library/std/range/recurrence.html. -- Andrei
>
> To be clear, by general you mean to allow functions with more than 2
> arguments?

My ambitions were lower :o). I was thinking of supporting any operation, not only summation.

> For example if you have:
>
> foo(int i, int j, int k) { return i + j + k; }
>
> then:
>
> scan!foo([1, 2, 3, 4]).array returns [1, 2, 6, 12]
>
> Is "scan" (thanks Timon) telling enough? The python "accumulate"
> conflicts with the C++ meaning.

That's a sliding window of compile-time-known size, which is interesting on its own. There are several ways to handle the limits, each useful in certain situations. I don't get where 12 comes from in your example.


Andrei

On 02/03/2016 10:18 AM, Atila Neves wrote:
> I guess this is to be a brand new PR? I've been reading the old one and
> the discussions. A lot of unanswered questions there and I have a new
> opinion on at least one of them.

If by the old one you mean the valiant effort to overload reduce, forget it. Just add fold as a one-liner that forwards to reduce. -- Andrei

On Wednesday, 3 February 2016 at 16:40:49 UTC, Andrei Alexandrescu wrote:
> On 02/03/2016 10:18 AM, Atila Neves wrote:
>> I guess this is to be a brand new PR? I've been reading the old one and
>> the discussions. A lot of unanswered questions there and I have a new
>> opinion on at least one of them.
>
> If by the old one you mean the valiant effort to overload reduce, forget it. Just add fold as a one-liner that forwards to reduce. -- Andrei

Ah, yes. That definitely makes more sense than me writing one from scratch this afternoon, which I totally didn't do... :P

https://github.com/D-Programming-Language/phobos/pull/3968

I think fold should be nothrow, but maybe that's just me. It's also a massive pain to make it that way, so I didn't for now.

Atila

On 02/03/2016 09:12 PM, Atila Neves wrote:
>
> https://github.com/D-Programming-Language/phobos/pull/3968
>
> I think fold should be nothrow, but maybe that's just me. It's also a
> massive pain to make it that way, so I didn't for now.

Returning Unqual!(ElementType!R).init makes no sense though.
The "correct" result of fold!f([]) is a (often, the) value 'a' such that for any 'b', 'f(a,b)==b' (which is the canonical choice of "seed"), but there is no way for fold to infer such a value.