Proposal: Relax rules for 'pure'

[Don]

Robert Jacques wrote:
> 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 is completely incorrect. It can only change strength if its 
signature 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.