should pure functions accept/deal with shared data?

[Andrei Alexandrescu]

On 6/6/12 8:32 PM, Alex Rønne Petersen wrote:
> On 07-06-2012 03:07, Andrei Alexandrescu wrote:
>> On 6/6/12 6:01 PM, Alex Rønne Petersen wrote:
>>> (And of course, neither is actually implemented in any compiler, and I
>>> doubt they ever will be.)
>>
>> Why do you doubt shared semantics will be implemented?
>>
>> Andrei
>>
>
> I think there are two fundamental issues making implementation difficult
> and unlikely to happen:
>
> 1) The x86 bias (I replied to your other post wrt this).
> 2) The overall complexity of generating correct code for shared.
>
> If we ignore the portability issues that I pointed out in my other
> reply, point (1) is irrelevant. I'm fairly certain the shared semantics
> that people expect can be implemented just fine at ISA level on x86
> without dirty hacks like locks. But if we do care about portability
> (which we ***really*** should - ARM and PowerPC, for example, are
> becoming increasingly important!), then we need to reconsider shared
> very carefully.

Agreed. I don't think (1) is irrelevant but I don't see it an impossible 
obstacle.

> The thing about (2) is that literally every operation on shared data has
> to be special-cased in the compiler.

Yes, like for volatile (no code motion etc) plus barriers.

> This adds a crazy amount of
> complexity, since there are basically two code paths for every single
> part of the code generation phase: the unshared path and the shared
> path. This is mostly caused by the fact that shared is transitive and
> can be applied to virtually any type. But even if we ignore that
> complexity, we have the problem of certain operations that cannot be
> atomic (even though they may look like it):
>
> * Would you expect an array indexing operation (where the array slice is
> shared) to index the array atomically? Would you expect the read of the
> value at the calculated memory location to be atomic?
> * Would you expect a slicing operation to be atomic? (Slicing something
> involves reading two words of memory which cannot be done atomically
> even on x86.)
> * Would you expect 'in' to be atomic? (It can only really, kinda-sorta
> be if you use locks inside the AA implementation...)

Operations with shared data are intentionally very limited. Indexing, 
slicing, and "in" should not compile for shared arrays and associative 
arrays.


Andrei