Exception transparency

[Nathan Bryant]

Sure, in the context of a @pure annotation, log.debug must be
disallowed.

 

However, you are then left with a tough choice: if the only mechanism
provided by a collections framework, to parallelize forEach(), is to
limit it to pure functions, then that would be seen as overly
restrictive by developers.

 

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

 

Don't we? I certainly want to. 

On Tue, Jun 8, 2010 at 4: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.