Exception transparency

[Nathan Bryant]

Reiner:

 

Ok gotcha. I think.

 

It seems to me that your particular definition of purity does not fit Brian’s desire to use the notion of purity to allow us to determine what’s thread safe. If a pure function were to call an impure function, it can no longer be guaranteed that it’s thread safe: the impure function might be mutating something, somewhere, either inside or outside the VM, on the pure function’s behalf. That mutation might not be thread safe. So in the most general sense, I/O is not pure.

 

From: reinierz at gmail.com [mailto:reinierz at gmail.com] On Behalf Of Reinier Zwitserloot
Sent: Tuesday, June 08, 2010 3:14 PM
To: Nathan Bryant
Cc: Paulo Levi; Brian Goetz; lambda-dev at openjdk.java.net
Subject: Re: Exception transparency

 

Nope; anonymous inner classes are pure, and they can access locals from outer scope. As long as they are final, though. The implementation shows why this holds: When a variable is final, a copy is indistinguishable from the original (and this is in fact how anonymous inner classes accessing outer final locals is done by javac). Therefore, access to an immutable variable from outer scope is no different from passing that variable along as a parameter to the closure, which is conceptually similar to currying that parameter into the closure. Which is clearly pure.


--Reinier Zwitserloot




On Tue, Jun 8, 2010 at 7:51 PM, Nathan Bryant <nathan.bryant at linkshare.com> wrote:

Reinier:

 

You mean A) directly or indirectly, right? A pure function may not access a mutable variable from another context… including statics, threadlocals, any big resource pool that’s hanging off of some static somewhere, or an object to which you have a reference… etc. In other words, a pure function may only call pure functions. No?

 

If this is not what you mean, then it seems to me that you are talking about the “weaker, more complex definition of pureness” that I was alluding to.

 

From: reinierz at gmail.com [mailto:reinierz at gmail.com] On Behalf Of Reinier Zwitserloot
Sent: Tuesday, June 08, 2010 1:39 PM
To: Nathan Bryant
Cc: Paulo Levi; Brian Goetz; lambda-dev at openjdk.java.net
Subject: Re: Exception transparency

 

Nathan, I don't think pure means what you think it means. Or I'm horribly confused, also an option.

 

"pure" at least in sofar I understand it within the confines of this discussion, simply means: "Does not assume that the runtime stack matches the lexical stack". No more, no less. So, everything is pure, unless it is a closure that does one or more of the following things:

 

A) Access a variable from lexical scope that is outside the closure itself. The variable isn't final, and isn't effectively final.

 

B) returns, breaks, or continues from inside the closure to outside the closure; i.e. the closure breaks a for loop in the containing method. (Not on the agenda for java7 closures so far, but nice to make possible, if not for java7, then for java 8)

 

C) throws a checked exception which is not handled by the closure (as in, the closure type doesn't have a "throws TheCheckedException" in its signature), but it IS handled by the containing method (either because the closure is defined in a try/catch block that catches that exception, or the containing method has a "throws TheCheckedException" clause).

 

 

Any closure that engages in none of those 3 things is pure. Pure does not mean "I have no side effects".


--Reinier Zwitserloot



On Tue, Jun 8, 2010 at 5:47 PM, Nathan Bryant <nathan.bryant at linkshare.com> wrote:

A simple example:

 

public @pure int sum(int a, int b) {

log.debug(“sum!”);

return a + b;

}

 

log.debug can never be strictly pure, but surely we don’t want to disallow it!

 

From: Paulo Levi [mailto:i30817 at gmail.com] 
Sent: Tuesday, June 08, 2010 11:44 AM
To: Nathan Bryant
Cc: Brian Goetz; Reinier Zwitserloot; lambda-dev at openjdk.java.net
Subject: Re: Exception transparency

 

Why is it not workable? Do programmers have trouble understanding that they can't use private methods outside of their class to give a foolish example?


Why would they have problems understanding that they can only use "pure" methods in the body of a pure function -recursive obvs? (aside, here you can see why constructors, and SAM types are still useful, mark a method as pure, but leave the constructor to deal with the impurity).

Seems like the most elegant solution, and frankly almost a requirement for that the new parallel api's if they are to maintain a little sanity. The alternative is to retrofit it later if the concept becomes available, that will break code, and thus be used as a excuse to do nothing, as usual.