Exception transparency

[Reinier Zwitserloot]

I already highlighted the notion that forEach automatically picking a
parallel algorithm in a 100% safe way is just not feasible within the
confines of project lambda; either the javadoc of forEach explicitly
explains that pure closures will be parallelized, or there's a separate
forEachParallel method.


Exception propagation can work in the parallel case. As I've explained,
there will be an "unrestrict this resticted variable" method. Its use cases
are extremely rare; PA is pretty much the only one (but an important enough
one to at least have that method).

--Reinier Zwitserloot



On Wed, Jun 9, 2010 at 3:02 AM, Nathan Bryant
<nathan.bryant at linkshare.com>wrote:

>   Reinier wrote:
>
>
>
> > Anything more drastic is definitely outside the scope of project lambda.
>
>
>
> Probably true.
>
>
>
> > I'm still very confused about what you're suggesting. Why do we need
> @pure and @impure?
>
>
>
> Well I’m not exactly saying it’s needed; I’m actually far from convinced
> that we need or even want them (my initial knee jerk was that this would
> just duplicate something that’s probably better done with “views”). What I’m
> am saying is that IF libraries make parallelization decisions based on
> pureness, THEN we need a way to override that behavior. @pure is one of the
> obvious ways to do that. Which is not to say it’s correct or useful, just
> obvious. But, these annotations would likely be needed if the definition of
> “pure” was any stronger than what you’re proposing.
>
>
>
> > Also, you're mixing things around. All lambdas are *PURE* unless you do
> something explicitly forbidden for pure closures, then they are
> automatically impure. There's no messy syntax at all because there is no
> @pure or @impure - closures are what they are.
>
>
>
> Following this to its logical conclusion, and continuing the tradition of
> using forEach() as an example, then what does one do about forEach()? It
> seemed like the idea was proposed that forEach() might automagically become
> parallel if the closure is pure. But this particular definition of pureness
> is too weak for that to be the entire basis of forEach()’s decision, or
> probably even a default. Your definition does seem to be useful as something
> that would produce a compiler warning: Iterator.parallel().forEach(foo)
> would produce a compile-time warning (or error?) if foo is impure by your
> definition. But that brings us to the question: how to squelch that error,
> which would involve annotations. Maybe it’s not necessary to be able squelch
> it at all – rewrite the code not to capture locals, instead, if intent on
> parallelizing.
>
>
>
> > The notion of purity / impurity I'm suggesting works similar. If you
> throw checked exception C from a closure, and the closure's signature
> doesn't allow throwing C, but your lexical scope *DOES*, then the compiler
> will always know exactly what you're trying to do. It may not compile it,
> though - that depends on whether or not an impure closure is allowed there.
>
>
>
> So exception propagation via this mechanism can only work in the sequential
> case. Which might be good, might be bad.
>