[API Proposal]: Extend the reduce and reduceBack to Collections

[fxdmhtt]

Background and motivation

From the requirements point of view: the fold function must provide init, reduce does not require init, which means no longer needs to write boilerplate "match with" code like "extract the first element from generic Collections as init, the remaining elements as sequence, and then pass it to fold".

From a reasonable point of view: list/array/seq all provide native reduce methods, list/array also provides native reduceBack methods. This generic encapsulation is not difficult to implement, and other languages ​​(except fundamental FPs like Haskell) generally provide reduce methods, which is reasonable.

I know there is a reduce function implementation now, but that one is very difficult to use. To be honest, I have no idea how to pass parameters.

API Proposal

let inline reduce (folder: 'State->'T->'State) (foldable: '``Foldable<'T>``) : 'State

let inline reduceBack (folder: 'T->'State->'State) (foldable: '``Foldable<'T>``) : 'State

API Usage

reduce (*) [1; 2; 3; 4; 5] |> should equal 120
reduce (+) ([]: int list) // throws an exception

Alternative Designs

No response

Risks

No response

Are you willing to help with a proof-of-concept (as PR in that or a separate repo) first and as pull-request later on?

Yes, please assign this issue to me.

[gusty]

The existing generic reduce function is a safe function, therefore it operates on Semigroups, more specifically collections which have at least one element.

The reduce functions provided in FSharp.Core are unsafe and although we're not free of unsafe functions here, we love to have some discussions before implementing them.

I think a good compromise could be to implement a tryReduce function. What do you think?

[fxdmhtt]

I think the idea of ​​implementing tryReduce is questionable.

1. This is a self-made name that does not exist anywhere else (as far as I know), which may cause ambiguity, misleading, or extra learning costs.
2. The reduce function provided in FSharp.Core is unsafe, which is not a reason to implement a safe reduce function. Functions with the same name should behave the same way, after all, we are just doing paradigm encapsulation.
3. We can also implement a safe reduce function, which is obtained by simplifying the boilerplate code. Specifically, even if the source parameter is actually an empty container (not null), it does not affect our return of Unchecked.defaultof<'State>. Of course, this may introduce other ambiguities,

So I think we should implement the tryReduce function and return the 'State option or something similar. Then keep reduce as an unsafe implementation that encapsulates FSharp.Core.

I would like to hear your opinions again.

[gusty]

If we decide to make reduce "unsafe", based on the fact that in FSharp.Core a function exists already with that name and it's unsafe, we should find another name for the existing safe version of reduce.

Then we have to consider backwards compatibilities, if it's not possible to guarantee, we'll have to hold to v2 for releasing it, however even in this case the PR won't be blocked.

[fxdmhtt]

Can we ignore "safety" for now and add the reduce paradigm function of seq/array/list in the current version?

The current reduce function cannot work on these three types, but these three types are the most commonly used types. So there is no conflict, as long as we are willing to ignore the "safety" issue.

[gusty]

We could, but not without adding (or renaming) the existing safe one.
Otherwise we'll be kind of losing functionality.
Any suggestion for the other function name ?

[fxdmhtt]

I believe in your wisdom

[gusty]

I'm not very creative this morning so at the moment I can just propose the name borrowed by Haskell's fold1.

However in Haskell that's a non-safe function, but we don't need to match them.

[BurningLutz]

For the renaming, why not just borrow from Haskell, that is foldl for safe reduce and foldr for safe reduceBack.

[fxdmhtt]

For the renaming, why not just borrow from Haskell, that is foldl for safe reduce and foldr for safe reduceBack.

This will lead to breaking updates and affect compatibility.

Personally, I think the root cause is that the current version of the API is poorly designed.

[fxdmhtt]

I also think that naming should first consider the consistent meaning in the F# context, and then borrow the conventions of Haskell.

[gusty]

For the renaming, why not just borrow from Haskell, that is foldl for safe reduce and foldr for safe reduceBack.

@BurningLutz those names are following a Haskell convention which doesn't match the one in F#. In F# the convention is, for the left, the function without any suffix and for the right, the function name with Back suffix.

This will lead to breaking updates and affect compatibility.

@fxdmhtt Hmmm, I don't see how it will affect compatibility, but ....

I also think that naming should first consider the consistent meaning in the F# context, and then borrow the conventions of Haskell.

... this is the main point here, we want to stick to F# naming conventions. I just mentioned Haskell the same way I could have mentions Scala or other language.

Personally, I think the root cause is that the current version of the API is poorly designed.

I agree that the API has room for improvement—no design is ever perfect. That said, I do think it’s worth mentioning that, relative to other F# libraries around, this one tries to follow a fairly disciplined approach to API design. Decisions about which functions to expose are made carefully, aiming for consistency and usability across a wide range of types—even if some of those use cases remain more theoretical than practical for now.

That said, if you feel there are fundamental issues with the current design, I’d genuinely appreciate it if you could point them out. I’m always open to improving things where it truly matters and we're collecting input for V2.

[fxdmhtt]

Hahahaha, I don't have the ability to find any "fundamental issues", I fully believe in your ability.

I just think that some official APIs need to be converted to proprietary data structures before they can be used in FSharpPlus, which is not convenient and will lead to a low usage rate of these APIs.

I would like to express my sincere gratitude for your hard work.

[gusty]

Thanks, I really appreciate your feedback and kind words.

some official APIs need to be converted to proprietary data structures before they can be used in FSharpPlus,

I'm not entirely sure what you mean here, but I’m guessing you're referring to the wrapping/unwrapping that's sometimes needed—especially to enable different behavior from generic operators.

If that's the case, I'd say a large portion of those situations were addressed with the relatively recent addition of non-sequential applicatives. With that in place, types like ZipList or Validation are much less necessary than they used to be.

That said, we’ll probably keep supporting them since the library is meant to offer multiple ways to approach a problem—so users can pick the one that best fits their style or use case.

[BurningLutz]

@BurningLutz those names are following a Haskell convention which doesn't match the one in F#. In F# the convention is, for the left, the function without any suffix and for the right, the function name with Back suffix.

@gusty I see, following the language's convention is important.

But I think I was confused by the conversation between you two.

You said:

The existing generic reduce function is a safe function, therefore it operates on Semigroups, more specifically collections which have at least one element.

Which reduce did you refer to? Is this one? But this one is a partial function, it is undefined when the reducible is empty, and a partial function is not considered to be safe.

Further, there really is a safe counterpart of reduce, the fold function. It is defined here.

So, both the unsafe reduce and the safe fold are defined in F#+.

Now I have no idea what's the problem here. Is it the problem that currently there is no Reduce static members defined for builtin collections like list/array/seq inside Foldable?

[fxdmhtt]

Now I have no idea what's the problem here. Is it the problem that currently there is no Reduce static members defined for builtin collections like list/array/seq inside Foldable?

Absolutely right