fn:reduce (or fn:fold without initial value)

[ChristianGruen]

fn:reduce (or fn:fold without initial value)

[michaelhkay]

I think that users who are sophisticated enough to be using fold/reduce functions have sufficient brain power to implement this for themselves.

[MarkNicholls]

I'm too unsophisticated to completely understand the issue.

I'm too lazy to implement it myself, and too incompetent to get it right first time or possibly second time.

I prefer an explicit named fold and reduce...I tend not to like overloaded functions, because typos type check and its a nightmare to find the error.

this would be a particularly wrinkly overload in my opinion.

What happens if the sequence over which you reduce is empty is the other issue?

I DONT use folds in xslt...I find them ugly and incomprehensible to most other developers, where other (xslt) constructs feel less scary.

in fp languages I nowadays prefer direct recursion, because syntactically it just seems clearer whats going on, so in xslt I would prefer iterate, which i suppose is just fold gone "smart casual" (that probably wont translate even to an english speaker).

[ChristianGruen]

I think that users who are sophisticated enough to be using fold/reduce functions have sufficient brain power to implement this for themselves.

@michaelhkay I’m not so sure about this. I would rather assume that it’s more obvious how to rewrite reduce to fold. reduce allows you to get rid of special-casing around the initial action (providing an empty sequence, or the identity element – 0 for additions, 1 for multiplications – is not always sufficient). I’m just not sure if it’s a good idea to bloat the spec with 4 new functions for every higher-order feature we add, which can possibly be processed from left-to-right and right-to-left, and run for sequences or arrays.

I prefer an explicit named fold and reduce...I tend not to like overloaded functions, because typos type check and its a nightmare to find the error.
…
What happens if the sequence over which you reduce is empty is the other issue?

@MarkNicholls Out of interest, as you’re most probably the one among us who’s most proficient in F#, are the following versions for F# correct, or would you write them differently?

List.fold   (fun acc x -> acc * x) 1 [1..5]
List.reduce (fun acc x -> acc * x) [1..5]

In Kotlin, I assume the syntax would be similar:

(1..5).fold(1) { acc, x -> acc * x }
(1..5).reduce { acc, x -> acc * x }

In our language, it would be:

fold-left(1 to 5, 1, fn($acc, $x) { $acc * $x })
reduce(1 to 5, fn($acc, $x) { $acc * $x })

For those trivial cases, though, it would obviously a waste of energy to add reduce.

[MarkNicholls]

@ChristianGruen

yes....you would write

List.fold (*) 1 [1..5]
just be be fancy and show off to your C# mates

my kotlins too rusty to comment,

(and to be fair, reduce is pretty obvious to derive from fold...so maybe its gold plating)

[ChristianGruen]

List.fold (*) 1 [1..5] just be be fancy and show off to your C# mates

;-) Thanks. In XPath, we now also have:

fold-left(1 to 5, 1, op('*'))

[ndw]

The CG agreed to close this issue without further action at meeting 072