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

[John A. De Goes]

On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote:
> 2009/08/14 John A. De Goes <john at n-brain.net>:
>> 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.
>
>  I think this is a bad example -- it's not something that's
>  safe in general and discredits your idea. How would the
>  compiler even know that two files are not actually the same
>  file?

I don't think the file system is the best example. However, I do think  
it's a reasonable one.

Let's say the type of the function getFilesInDir is annotated in such  
a way as to tell the effect system that every file in the returned  
array is unique. Further, let's say the type of the function  
makeNewTempFile is annotated in such a way as to tell the effect  
system that the function will succeed in creating a new temp file with  
a name unique from any other existing file.

Then if you write a recursive function that loops through all files in  
a directory, and for each file, it parses and compiles the file into a  
new temp file, then a sufficiently sophisticated compiler should be  
able to safely transform the recursion into parallel parsing and  
compilation -- in a way that's provably correct, assuming the original  
program was correct.

The promise of a language with a purely functional part and a powerful  
effect system for everything else is very great. And very important in  
the massively concurrent world we are entering.

>  Well, yes -- which sounds like, there are no guarantees
>  in general. Something that works half the time leaves you with
>  two responsibilities -- the old responsibility of the work you
>  did when you didn't have it and the new responsibility of
>  knowing when it applies and when it doesn't.

In the other thread, I brought up the example of buffering reads.  
Library authors make the decision to buffer for one reason: because if  
some other program is messing with the data, you're screwed no matter  
what.

And yeah, "they might be screwing with the data in just the way you  
need it to be screwed with," (Sebastian), in which case my advice is  
use C and hope for the best. :-)

Regards,

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

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