DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)

[John A. De Goes]

On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote:

> On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes <john at n-brain.net>  
> wrote:
> If you don't like the file system, consider mutable memory. An  
> effect system will tell me I can safely update two pieces of non- 
> overlapping, contiguous memory concurrently, even in different  
> threads if the complexity so justifies it.
>
> I'd like to point out that this relaxation of sequencing for memory  
> operations is already in effect in C on many CPUs. Even though you  
> write things sequentially, it doesn't actually happen sequentially  
> unless you explicitly say so with memory barriers. This causes  
> massive head-aches and horrible bugs that are almost impossible to  
> track down whenever you actually do depend on the order (usually in  
> multi-threading scenarios, e.g. lockless data structures).

That's because C has no effect system and is too low-level for an  
effect system. That's no argument against one in a high-level language  
similar in syntax to Haskell.

> The point is, the safer option is to enforce a sequential model  
> (like Haskell does), since that way you can always rely on ordering  
> even if you don't even realise you need to, and there's plenty of  
> practical experience indicating that the other option (explicit  
> barriers to indicate when something isn't commutative) is sheer  
> madness.

Your point about safety in C has no relation to safety in a functional  
language with a sophisticated effect system. Haskell enforces a  
sequential model not because it's safer (it's NOT), but because it's  
simpler and because it's the best Haskell monads can do.

Unfortunately, it doesn't fly in a world with dozens of cores.

Regards,

John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration

http://www.n-brain.net    |    877-376-2724 x 101
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090815/08df147f/attachment.html