Review request for initial lambda functions and utils

[Peter Levart]

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.

Regards, Peter

> 
> 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
> >
> >
> 
>