LACSS 2009: Domain Specific Languages and Haskell

on the use of Haskell for constructing EDSLs for high performance computing, along with a 10 minute overview of Haskell support for multicore programming, presented at the LACSS 2009 Workshop on Non-Traditional Programming Models.

As the complexity of large-scale computing architecture increases, the effort needed to program these machines efficiently has grown dramatically. The challenge is how to bridge this “programmability gap”, making the hardware more accessible to domain experts. We argue for an approach based on
executable embedded domain specific languages (EDSLs)—small languages with focused expressive power hosted directly in existing high-level programming languages such as Haskell. We provide examples of EDSLs in use in industry today, and describe the advantages EDSLs have over general purpose languages in productivity, performance, correctness and cost.

4 comments

I completely agree with what you’re saying (and wish I’d been there to see it in person). I think there’s a lot of opportunity to build an EDSL that effectively and efficiently straddles a number of different computational models (CPUs, GPUs, FPGAs, “cloud resources”, etc.).

I think Haskell’s suitability for EDSL’s is sort of an accidentally emergent quality that still requires a lot of kludges to really use effectively. If EDSL’s are supposed to be an important Haskell application area, it may be worth thinking about how to extend Haskell or GHC to help with EDSL implementation. I’m imagining something along the lines of Liskell, a sort of Template Haskell relative that let you juggle abstract parse trees of Haskell code while still making sure the results were type-checked.

I’ve been interested for a while in Hedgehog Lisp, a tiny functional Lisp dialect intended for embedded systems. It would be awesome to have a statically typed variant of it and a Haskell EDSL is the obvious approach. But while it’s easy to imagine the code inside Hedgehog functions as monadic actions, it’s not so obvious how to express (e.g.) the function definitions themselves.

Maybe there could be an “edo” syntax (embedded do) analogous to mdo. Among other things all the normal Haskell imports including the Prelude could be completely hidden inside an edo block, so you wouldn’t have to say stuff like “a .+. b” all the time. Then you’d get a Liskell-ish parse tree which you could rewrite, type-check, and generate code from.