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

John A. De Goes john at n-brain.net
Wed Aug 12 23:56:18 EDT 2009


The next step is to distinguish between reading file A and reading  
file B, between reading file A and writing file A, between reading one  
part of file A and writing another part of file A, etc. When the  
effect system can carry that kind of information, and not just for  
files, but network, memory, etc., then you'll be able to do some  
extremely powerful parallelization & optimization.

But for now providing course grained information on the class to which  
an effect belongs is pretty interesting in its own right.

Regards,

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

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

On Aug 12, 2009, at 9:41 PM, Ben Lippmeier wrote:

> Dan Doel wrote:
>> For instance: what effects does disciple support? Mutation and IO?
> You can create your own top-level effects which interfere
> will all others, for example:
>
> effect !Network;
> effect !File;
>
> readFile :: String -(!e)> String
>        :- !e = !File
>
> Now any function that calls readFile will also have a !File effect.
>
>> What if I want non-determinism, or continuations, etc.? How do I as  
>> a user add those effects to the effect system, and specify how they  
>> should interact with the other effects? As far as I know, there  
>> aren't yet any provisions for this, so presumably you'll end up  
>> with effect system for effects supported by the compiler, and  
>> monads for effects you're writing yourself.
>>
> Yep.
>
> In Disciple, a computation has an effect if its evaluation cannot
> safely be reordered with others having the same effect. That is,
> computations have effects if they might "interfere" with others.
>
> One of the goals of the work has been to perform compiler
> optimisations without having to use IO-monad style state threading.
> "IO" is very coarse grained, and using the IO monad for everything
> tends to introduce more data-dependencies than strictly needed, which
> limits what optimisations you can do.
>
> Non-determinism and continuations are tricker things than the simple
> notion of "effects-as-interference", which I haven't got a good
> solution for.
>
> Ben.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list