
I knew about DDC for a while but never bothered to look at it deeply since it was so young, and at first sight it just did what ML did (silently allowing side effects). But when looking again at it, it seems it actually does some very clever things to allow side effects and still be safe, a bit what one does explicitly with Haskell's ST and IO monads, but in DDC, the compiler seems to analyze where side effects happen and automatically annotates/enrich the types (with things like region, closure and effect information) to indicate this. The example given by DDC is that in Haskell, you need two versions of each higher order function if you really want your library to be reuseable, e.g. you need map and mapM, but in DDC you just need one function, map, which also is written in a pure style. See e.g. http://www.haskell.org/haskellwiki/DDC/EffectSystem I kind of agree with the DDC authors here; in Haskell as soon as a function has a side effect, and you want to pass that function to a pure higher order function, you're stuck, you need to pick the monadic version of the higher order function, if it exists. So Haskell doesn't really solve the modularity problem, you need two versions of each higher order function really, and you need to carefully plan ahead of time if you want to write in a monadic or pure style, and it also splits my brain mentally ("side effects are ***evil***. But hang on, how can I e.g. do a depth first search efficiently purely functional? Damn, it seems I can't! Let's switch back to C#/C++!!! Nooooo ;-) This seems to make Haskell not a good language for doing things like extreme programming where code evolves, unless you have some insanely clever refactoring tool ready that can convert pure into monadic functions and vice versa. Is it true that - as in DDC - side effects can be analyzed by the compiler (in the same sense that say, strictness is analyzed), freeing the library and user from writing/picking monadic versions??? If so, would this indeed solve the modularity/reusablity issue? I feel you can't have your cake and eat it here, so there must be catch? :-) Thanks for sharing any thoughts on this, Peter Verswyvelen