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@gmail.com>
2009/08/12 John A. De Goes <john@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