Proposal: Relax rules for 'pure'

[Robert Jacques]

On Wed, 22 Sep 2010 11:44:00 -0400, Don <nospam at nospam.com> wrote:

> Robert Jacques wrote:
>> On Wed, 22 Sep 2010 07:54:26 -0400, Michel Fortin  
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2010-09-22 01:26:01 -0400, "Robert Jacques" <sandford at jhu.edu> said:
>>>
>>>> So removing the concurrency safety from pure would greatly  expand  
>>>> the number of pure functions, however, automatic parallelism would   
>>>> be lost.
>>>
>>> Don clearly mentioned that this is not lost. Basically, for safe  
>>> parallelism what you need is a function that has a) pure and b) no  
>>> mutable reference parameter. Both are easily checkable at compile  
>>> time, you'd just need to change your test for pure for a test that  
>>> also checks the arguments.
>>  What is lost is my ability to declare a function does x in the  
>> signature and for the compiler to check that. I really want to know if  
>> code monkey A changed some type's implementation to be thread unsafe,  
>> because detecting and tracking down a loss of performance due to loss  
>> of automatic parallelism is devilish.
>
> No, you haven't lost that at all. Any function marked as pure still has  
> no access to any state, other than what is provided by its parameters.  
> It is still thread-safe.

No, it isn't. A strongly-pure function is thread safe, but a weakly-pure  
function isn't. Since strong/weak is automatically determined by the  
compiler, a function's strength can switch due to long distance code  
changes. This wouldn't be an issue today, but tomorrow large strongly-pure  
functions will be parallelized automatically in a manner akin to inlining  
(outlining?). Then it makes a difference. However, these issues feel more  
like D3 concerns than D2 concerns, particularly when you consider the  
advantages of making tasks/futures a language level concept.