Review request for initial lambda functions and utils
peter.levart at marand.si
Tue Aug 9 10:54:14 PDT 2011
On 08/09/11, Neal Gafter wrote:
> Perhaps I don't fully understand the semantics of Blocks.repeatUntil. It
> appears to repeatedly invoke the predicate on the same value of t. Is it
> supposed to be passing different values of t to the predicate, or is the
> predicate really expected to return the same value each time? If it is the
> same value of t each time, why is the predicate invoked repeatedly? Why is
> the value of t not captured within the lambda in the caller?
I think the intent was that Block would change the state of t in each iteration and Predicate would just evaluate the state of the same t before or after each iteration.
But yes, repeatUntil, as documented, is inherently sequential. I find the Block SAM itself and any API that uses it as inherently sequential, since it does not have any return value and any sensible implementation therefore must have side-effects.
> If the predicate can change its returned value, then I find the existence of
> facilities like Blocks.repeatUntil - inherently sequential and relying on
> side-effects - really surprising in the context of project Lambda. So far
> project Lambda has held as one of its design principles supporting
> inherently parallelizable facilities (which means side-effect-free
> lambdas). That is, as I understand it, the reason that lambdas cannot
> access mutable locals. An inherently sequential method such as repeatUntil
> would be more consistent with a language design in which lambdas can access
> mutable locals.
> On Mon, Aug 8, 2011 at 8:02 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
> > Late last week I committed an initial version of the proposed standard
> > basic lambda functions and some utils for those functions to the OpenJDK
> > lambda repository. The implementation (especially the oh-so-tedious-javadoc
> > and unit tests) is still very rough but we are interested in hearing
> > feedback. For now focus your feedback on:
> > - approach
> > - Is there a different way to solve the problem?
> > - completeness
> > - What *must* be there that is missing?
> > - stylistic/usage issues
> > - Copying inputs vs to not copy inputs--see Predicates.contains() vs.
> > Predicates.or(Predicate<T>... )
> > - surprising behaviour
> > - self-inconsistency or surprising behaviour with respect to other Java
> > APIs.
> > - usage problems
> > - I can't use this to X
> > This API will see incremental progress in the next couple of weeks. Over
> > time other useful bits such as extension methods for Collection, List, Set
> > utilizing lambda functions will also appear.
> > Mike
More information about the lambda-dev