lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]

Rémi Forax forax at
Thu Mar 10 14:44:59 PST 2011

map() or filter() are defined as using the collection's iterator.

so  => 4


On 03/10/2011 11:29 PM, John Nilsson wrote:
> What does it mean to map a Set?
> Let's say I have a set s = {"1+1","2"}
> does give me 2 or 4?
> (Assuming eval and + stands for the obvious)
> BR,
> John
> On Thu, Mar 10, 2011 at 8:10 PM, Brian Goetz<brian.goetz at>  wrote:
>> I think people are getting hung up on the (entry level) serial/eager
>> model, which is largely only an on-ramp.
>> In the serial/lazy model, there is only one iteration as elements stream
>> through the computation, so separating into separate filter/map/reduce
>> steps doesn't really create a "second iteration".
>> In the parallel/lazy model, the same is true: the runtime can identify
>> which operations can be jammed together into a single parallel pass
>> (e.g., filter/map/reduce).
>> On 3/10/2011 9:48 AM, Seamus Sullivan wrote:
>>> The use of fold in functional programming makes perfect sense, as they tend
>>> to support tail-call recursion - which has some rather nice performance
>>> benefits.
>>> To get back on point a bit, the key element of fold in ML (I'm sure it's
>>> just as true in other fp languages) is that of the accumulation function
>>> performed within the fold - which allows a type transformation to take place
>>> - what do you gain by limiting the return type of the binary function?  By
>>> limiting the return type of the accumulator, the expressiveness of fold is
>>> limited, so there is a very definite loss that happens.
>>> I have used the accumulate template function in C++'s standard library to
>>> perform processing on collections of relatively complex objects that
>>> returned relatively simple results: computing the average quality assessment
>>> of a collection containing complex data comes to mind - my point is that the
>>> transformation from a class of some sort to a primitive type was relatively
>>> common inside the fold.  Yes, this could have been done in two steps -
>>> performing a map and then a simply-typed fold/reduce, but why split this
>>> into two iterative operations when it seems natural to think of it as one
>>> collective action performed within some sort of loop?  I would find it odd
>>> to have to iterate twice over every collection I wanted to run a fold
>>> operation on.
>>> Seamus
>>> -----Original Message-----
>>> From: lambda-dev-bounces at
>>> [mailto:lambda-dev-bounces at] On Behalf Of Lawrence Kesteloot
>>> Sent: Tuesday, March 08, 2011 3:38 AM
>>> To: lambda-dev at
>>> Subject: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]
>>> On Mon, Mar 7, 2011 at 6:30 PM, Neal Gafter<neal at>    wrote:
>>>> It would be a shame to ignore [the functional programming community's]
>>> experience
>>>> and repeat mistakes of the distant past.
>>> Their mistake of the distant past was to use fold-left in the first place.
>>>> for some simple examples,<Matt Malone's blog post "Lots And Lots Of
>>>> foldLeft
>>> Examples"<
>>> ft-examples/>
>>> I assert that every single one of those examples would be more clearly
>>> (if more verbosely) expressed as a for-loop. (I tried this myself and
>>> it's striking how much clearer the for-loop is, and often more
>>> efficient.) I can genuinely see why computer science theorists love
>>> fold-left, but it doesn't belong in any code that will later be read
>>> by a human. Java should follow the example of Python 3000 and remove
>>> fold-left from the API.
>>>> Being composed of experts, I expect that the Project Lambda JSR expert
>>> group
>>>> has members who are well versed in these techniques.
>>> I'm hoping for exactly the same thing.
>>> Lawrence
>>> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

More information about the lambda-dev mailing list