Joel Reymont:

I need to pick among the usual list of suspects for a commercial product that I'm writing. The suspects are OCaml, Haskell and Lisp and the product is a trading studio. My idea is to write something like TradeStation [1] or NinjaTrader, only for the Mac.

It would be quite nifty to use SPJ's financial combinator approach and, for example, embed Yi (Haskell editor).

One of the key features of the product would be the ability to model your trading logic using a trading DSL. I'm thinking that this DSL could well be Haskell but I'm concerned about stepping into a minefield.

I will need to embed GHC into the app, for example, and I understand that the GHC API does not offer unloading of code at the moment. I would prefer not to bundle GHC separately so I don't think the hs- plugins approach would work for me. Maybe I'm mistaken.

I don't see how embedding GHC into the app is any more or less complicated than bundling it with the app. Hence, I'd actually start with hs-plugins and see whether that's sufficient. If hs-plugins is sufficient for your purpose, it's surely simpler (by virtue of a much smaller API) and does code unloading just fine.

Most of all, I'm concerned that my users will need to face the error reports from GHC and could get tripped by laziness, i.e. write something that would make the app run out of memory. Off the top of my head I can't figure out a way to limit what my users can do without analyzing the Haskell AST within the GHC API and complaining if necessary.

Error message are always an issue with embedded DSLs, independent of whether you use Haskell, OCaml or Lisp. The same holds for running out of memory and for inadvertently coding unbound recursion or loops. An *E*DSL comes with the full power of the host language for better or worse. You can sandbox the EDSL code to varying degrees to shield the end- user from such problems; eg, use asynchronous exceptions to spot and terminate long running computations and use AST inspection to prevent the use of certain language features. Incidentally, hs-plugins already has some support for this, based on haskell-src (again that's a simpler API then the GHC API). With errors messages you can add some post-processing before presenting them to the user. One possible approach is to run with an EDSL for starters, sandbox the execution of EDSL components, and post-process error messages. This will get you a prototype quickly with which you can collect some experience. If you find that, eg, the error messages are too often too cryptic then you can turn you EDSL into a DSL by writing a parser for the DSL in parsec, do static checks and error reporting on the DSL AST, and finally translate the DSL AST into the corresponding EDSL code. The last step is barely more than pretty printing and enables you to reuse almost all the effort that you put into the EDSL development. In this way you get the quick prototyping advantage of the EDSL without prematurely committing yourself to either an EDSL or DSL approach.

Can someone with experience in offering a Haskell DSL to their users please comment?

Notice that I'm not even mentioning being concerned with the unpredictable effects of laziness. There's probably a reason why Jane St Capital is using OCaml instead of Haskell. I'm not going to play in that league but my knee-jerk reaction is to use OCaml or Lisp and avoid laziness altogether. I just can't see how laziness can help in processing real-time price data.

I strongly suspect the reason that Jane St Capital is using OCaml is because the people who started the coding already knew OCaml and stuck with what they know and love. Laziness, in particular, and Haskell, in general, is going to help you with the EDSL (it's no coincidence that most EDSL work was done in Haskell). Otherwise, I don't see why laziness is going to be a big obstacle. Lennart has just recently nicely demonstrate that Haskell performance even in numeric applications is no worse than OCaml's: <http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.htm...

In fact, in this benchmark, Haskell performance turned out to be better.

A second data point is xmonad which is often commended for its responsiveness, in a domain where the competition is using C. Manuel