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

Peter Verswyvelen bugfact at gmail.com
Wed Aug 12 05:00:07 EDT 2009


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


More information about the Haskell-Cafe mailing list