DDC compiler and effects; better than Haskell? (was Re:
Alberto G. Corona
agocorona at gmail.com
Thu Aug 13 06:09:08 EDT 2009
Another issue in DCC is in the course of writing a procedure, is that either
the programmer has too much information (the list of effects of all the
called procedures if they are explicit), or too little, if they are
generated and managed by the compiler.
How he knows for sure that a variable to be used in the next statement is
pure or it would be updated by the previous function call?. if the list of
effects of a procedure is hidden or worse, contains a lot of information,
Isn`t this a problem?.
In contrast, the division of the world in pure/impure operations is
relaxing. Ok , after the @ operator I´m sure that everithing is pure, but
things are not clear outside. At least in Haskell, trough monads, we have a
clear signature about the effects we are dealiing with. If IO can be
considered an effect.
Maybe, in Haskell, the coarse IO monad can be divided in smaller monads as
well, in the same but reverse way than DCC can handle the whole IO as a
single effect (I guess)?
2009/8/13 Jason Dusek <jason.dusek at gmail.com>
> 2009/08/12 John A. De Goes <john at n-brain.net>:
> > 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.
> I am challenged to imagine optimizations that would be safe in
> the case of File I/O.
> Jason Dusek
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe