Exception transparency

[Nathan Bryant]

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.