Exception transparency

[Paulo Levi]

Specifically, that concern is simply irrelevant compared to the possible
gains on type safe concurrency. The terrible concurrency bugs i have seen...
and i am not a concurrency guy.

On Tue, Jun 8, 2010 at 4:55 PM, Paulo Levi <i30817 at gmail.com> wrote:

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