The functional programming language community seems to be moderately abuzz over the recent release of the Disciplined Disciple Compiler. The first announcement I saw for it I ignored almost completely. Dialect of Haskell, allows destructive updates, allows mixing lazy and strict, etc. None of that really grabbed me.
Then this afternoon I saw another blog mentioned it on the Planet Haskell feed. This time it was mentioned with the phrase “region, effect, and closure inference” and immediately I had to read more about it.
The compiler seems to be a Google summer of code project by an Australian Ph.D. student. There is no paper yet! This means trying to figure out what’s going on involves combing through all the wiki pages and reading some tea leaves. Regions—à la Tofte—are not used for memory allocation. Darn! They seem to be used as part of the effect system, e.g., to mark certain regions of memory as being pure/constant/read-only or allowing destructive updates.
All of the magic is in the type system. It looks very well thought-out and very rich and is all orthogonal to the usual Haskell type system.
It looks like an interesting language to follow. I shall be keeping track of its developments.
From a syntactic stand-point, it seems to further my belief that you need to choose a “side” on the strict versus lazy issue. Disciple should in theory nicely and transparently mix strictly evaluated expressions with lazily evaluated ones. In practice this means things are strict by default but can be made lazy with annotations.
In my mind, what defines a language as being “strict” or “lazy” is the standard library. A language which truly is agnostic on the issue should allow, for example, map to be used in either a strict or lazy manner rather than having both a strict map and a lazy map. I don’t see an easy way to get this, so for the time being it seems languages have to pick sides.
In a similar vein, one of the nice features of Disciple is that its effect system ends the duality in Haskell between pure and impure functions. For instance, in Haskell you have a map which works on pure functions and a mapM which works on monadic functions. No such division exists in Disciple.
March 26, 2008 at 7:28 am
Thanks for the post!. DDC isn’t sponsored by Google SoC, but I do use their Google Code service to host the bug tracker and download.
I have a vague plan for using the regions to do some allocation, but regions won’t yield as much of a speedup as you might think. The original papers added region allocation to a (now somewhat dated) two space collector, and noted that most of the (modest) speedup came from locality improvements – which you’ll get from a good generational collector anyway.
Also, region allocation isn’t a total replacement for garbage collection because it doesn’t perform well when applied to objects who’s lifetimes don’t follow the natural block structure of the source code. It’ll end up placing these objects in regions which live too long, resulting in space leaks.
March 26, 2008 at 8:03 am
Thanks for the post, Ben! The project looks awesome!
One thing I didn’t glean from it was the motivation. What’s the intended purpose of the language/compiler? Performance?
March 29, 2008 at 12:35 am
Yes. That and making destructive update a first class citizen of the language – which is hard to do when laziness is the default. Down with IORefs!