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

[John A. De Goes]

Hmmm, my point (perhaps I wasn't clear), is that different effects  
have different commutability properties. In the case of a file system,  
you can commute two sequential reads from two different files. This  
has no effect on the result of the computation, assuming no  
interference from other programs -- and if there _is_ interference  
from other programs, then guarantees go out the window, _with or  
without_ commuting.

Monads are an insufficient structure to capture the fine semantics of  
effects. Something more powerful is needed. And in general, the way  
effects combine and commute is quite complicated and needs to be baked  
into the effect system, rather than being the responsibility of a  
lowly developer.

Regards,

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

http://www.n-brain.net    |    877-376-2724 x 101

On Aug 13, 2009, at 12:24 PM, Sebastian Sylvan wrote:

>
>
> On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes <john at n-brain.net>  
> wrote:
>> What if you have another program, written in C or something, that  
>> monitors a file for changes, and if so changes the contents of  
>> another file? Surely to catch that you must mark *all* file system  
>> access as "interefering"? Even worse, another program could monitor  
>> the state of a file and conditionally disable thet network driver,  
>> now file access interferes with network access.
>
>
> A compiler or runtime system can't know about these kinds of things  
> -- unless perhaps you push the effect system into the operating  
> system (interesting idea). The best you can do is ensure the program  
> itself is correct in the absence of interference from other programs
>
> I think the best you can do is make sure any code which is  
> vulnerable to such interference won't be subject to unsafe  
> transformations (like changing the order of evaluation).
> So I do think pretty much anything that relies on the outside world  
> needs to go into one big effects "category" so the compiler/runtime  
> will "stay out" and let the programmer explicitly define the  
> ordering of those operations, precisely because the compiler has no  
> way of knowing anything about what kind of assumptions are in effect.
>
>
> -- 
> Sebastian Sylvan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090814/e1be189e/attachment.html