pointers for EDSL design
Hello, I'm working on a prototype edsl (my first one), and I was wondering if there are any resources that discuss pros and cons of various implementation issues? I'm trying to decide what should be included in the edsl vs. re-using the meta language implementations (e.g. let-binding, lambdas). Most of the examples I've found are for full DSL's, not EDSL's, so it's not clear what the best approach is. The LLVM interface is sort of close to what I intend, except it creates a very imperative style whereas I'm aiming for something more functional. A little background: I decided on a dsl because I intend to make heavy use of Haskell functions from Data.List and Control.Monad. If I made a full DSL I would need to re-implement much of that functionality, so I thought it would be more sensible to use an edsl. Any advice or references would be very much appreciated. Best, John
Any advice or references would be very much appreciated. Best,
Please check out the EDSL around the software build domain - * slides http://www.galois.com/~dons/talks/hiw-2010/ndm-shake.pdf * video http://www.vimeo.com/15465133 This one is around the music composition domain http://www.haskell.org/haskore/onlinetutorial/index.html I could not gather the domain you are trying to target. -- Regards, Kashyap
Hello John If you are wanting variables, lambdas ... it sounds like you might be "off-shoring" - i.e. building a little language within Haskell that is executed on something else GPU (compiled to CUDA), compiled to C, compiled to VHDL, etc. Generally this is a "deep-embedding" as you need to produce output code for the target system. There are many papers on this - as for a survey of techniques there is one by Keon Claessen and Gordon Pace that gives an (albeit brief) comparison of shallow and deep embedding for Hardware EDSLs - "Embedded Hardware Description Languages: Exploring the Design Space". Also, the recent Kansas Lava combines a shallow embedding and a deep embedding so it can "run" in Haskell but compile to Verilog or VHDL(?). Andy Gill and colleagues have various papers describing its design. Robert Atkey and co-authors had a paper at the 2009 Haskell Symposium "Unembedding domain-specific languages". Conal Elliott's Pan was one of the first Haskell offshore DSLs (maybe the first?), there is a paper "Compiling Embedded Languages" written with Sigborn Finne and Oege de Moor. The authors acknowledge Samuel Kamin's previous work in ML. Later Conal Elliott had a paper describing Vertigo on GPUs. Quite a few papers have popped up recently about off-shoring "subsets" of Haskell to GPUs, see Joel Svensson's Obsidian and GPUgen by Manuel M. T. Chakravarty and colleagues. Oleg Kiselyov, Jacques Carette and Chung-chieh Shan have papers describing embedded DSLs in the "tagless" style. There are also papers by Jacques Carette and Oleg Kiselyov describing deep embedding in Ocaml - I think they coined the term "off-shoring", here's one: http://www.cas.mcmaster.ca/~carette/publications/scp_metamonads.pdf
Stephen's list is great! Two more points of reference from the recent ICFP -- Geoff Mainland's Nikola [1], and a nice talk on Kansas Lava [2]. [1] http://www.eecs.harvard.edu/~mainland/publications/ [2] http://www.scribd.com/doc/38559736/kansaslava-hiw10 -- hopefully the video from the implementor's workshop to appear soon. I suspect however, that it will prove hard to impossible to reuse Data.List and Control.Monad functions directly. You don't want to invoke functions at compile time, but represent invocations. Cheers, Sterl.
Thanks for these, and also Stephen's extensive list. I think it's fair to
say that I'm just exploring the space and don't know what I'm doing yet. As
such, I'm pretty open to exploring ideas. I'm only familiar with a small
fraction of these, so I've got some reading to do now!
For my toy language I've been working on a csound-like DSP language which is
compiled to Csound code (I am slightly familiar with Atom, and moreso with
Feldspar, but they're both quite different in usage style from what I'm
aiming at). Essentially the Csound module from Haskore, but less verbose
and typed. I've implemented it in a final-tagless style (at least as far as
I understand Kiselyov, Carette, and Shan), which has the very nice benefit
that even though I'm currently targetting csound I could target other
languages relatively simply.
When I said I wanted to use functions from Data.List and Control.Monad, I
meant that I wanted to use them to manipulate expressions in the edsl, which
has worked very well so far. In fact everything has worked so well, and has
been so simple to implement, that I figure I must be missing something
important.
John
On Tue, Oct 5, 2010 at 4:29 PM, Sterling Clover
Stephen's list is great! Two more points of reference from the recent ICFP -- Geoff Mainland's Nikola [1], and a nice talk on Kansas Lava [2].
[1] http://www.eecs.harvard.edu/~mainland/publications/ [2] http://www.scribd.com/doc/38559736/kansaslava-hiw10 -- hopefully the video from the implementor's workshop to appear soon.
I suspect however, that it will prove hard to impossible to reuse Data.List and Control.Monad functions directly. You don't want to invoke functions at compile time, but represent invocations.
Cheers, Sterl.
Hi John For the user level stuff, I don't think CSound really has "functions" - either for the score or orchestra. The score I think is just a list of /notes/ with many, many parameters and the orchestra is a graph description saying how the UGens are connected. This is good news - I believe Pan, Feldspar, Lava etc. generate functions or procedures in the output code which means they have to involve the complicated techniques for embedding lambdas and functions in the EDSL. If they didn't, there would be massive code blow up. However because CSound is more or less "straight line" code - i.e. lines are interpreted sequentially, there are no procedures or functions to define and call - generating it should be much simpler. Andy Gill's Dot package on Hackage has a crafty, but simple technique to allow you to reference graph nodes and link them within a monad and output as "foreign" code - here dot files. Something similar might be satisfactory for orchestra files. Of course if you want to generate UGens in C things get complicated again, but you still might be able to generate UGens as single monolithic functions. I think Roger Dannenberg's Nyquist generates UGens in this way from a Scheme like macro language, but its a long time since I looked at it. Best wishes Stephen
John Lato schrieb:
Thanks for these, and also Stephen's extensive list. I think it's fair to say that I'm just exploring the space and don't know what I'm doing yet. As such, I'm pretty open to exploring ideas. I'm only familiar with a small fraction of these, so I've got some reading to do now!
For my toy language I've been working on a csound-like DSP language which is compiled to Csound code (I am slightly familiar with Atom, and moreso with Feldspar, but they're both quite different in usage style from what I'm aiming at). Essentially the Csound module from Haskore, but less verbose and typed. I've implemented it in a final-tagless style (at least as far as I understand Kiselyov, Carette, and Shan), which has the very nice benefit that even though I'm currently targetting csound I could target other languages relatively simply.
Have I already advertised my realtime LLVM sound signal processing package? http://arxiv.org/abs/1004.4796 http://hackage.haskell.org/package/synthesizer-llvm http://www.youtube.com/watch?v=GNiAqBTVa6U
participants (5)
-
C K Kashyap -
Henning Thielemann -
John Lato -
Stephen Tetley -
Sterling Clover