Open michaelhkay opened 7 months ago
Although this seems not too-meaningful for folds and scans (and I have the expressed opinion by @AdamRetter saying "I agree that fn:fold-left and fn:fold-right functions should not have index arguments.) ", I would not object to this if the additional argument is in a separate overload. Thus, if we have two separate overloads, the first one as is now - with the $action
argument being a function of 2 arguments, and the second one with the $action argument being a function of 3 arguments.
Combining these two overloads into a single one is not only formally problematic, but also requires unnecessary mental gymnastics for the reader to clearly understand the specification, when this issue would completely be non-existent if we had two separate overloads.
Consistency is very hard to achieve in a language designed by committee, but it's not acceptable to have two different functions do the same thing in different ways just because they were put forward by different people. If we make a change to the way this is done, it needs to be done across the board, not just in one function.
Consistency is very hard to achieve in a language designed by committee, but it's not acceptable to have two different functions do the same thing in different ways just because they were put forward by different people. If we make a change to the way this is done, it needs to be done across the board, not just in one function.
Microsoft is a good example of producing a language that is not designed by committee, and yet they decided not to add an overload where the $action argument is a function that has the position in the collection as an added new argument.
Why Microsoft didn't do this in the specification of Enumerable.Aggregate method ?
Not because they missed something (we are at ver. 8 of .NET, and LINQ was introduced almost 20 years ago - in ver.3, so they have had plenty of time to notice and correct any omissions), but because they decided (as both @AdamRetter and I concur) that this has little meaning, if any at all.
In addition, we should add array:scan-left
and array:scan-right
. My suggestion would be to be less paternalistic and align the result types of fn:scan-(left|right)
with fn:for-each
, and to use the array functions for structured results. Of course, nothing prevents a user from creating structured results with fn:scan-(left|right)
as well.
We have added an optional position argument to nearly all callback functions that are invoked once for each item in a sequence. This argument is omitted from the new scan-left and scan-right functions. It should be added for consistency.
One of the proposed use cases for scan-left and scan-right is for debugging calls on fold-left and fold-right. This use case requires that the callback functions in the two cases are compatible.
Background note: the optional position argument is modelled on Javascript, where it is permitted in all the common higher-order functions such as
filter
,forEach
,reduce
andreduceRight
(which are the Javascript equivalent of fold-left and fold-right). Javascript doesn't appear to offer an equivalent ofscan-left
andscan-right
.