[Haskell-cafe] Should I step into a minefield? / Writing a
trading studio in Haskell
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Wed Nov 7 23:38:11 EST 2007
> 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  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
> 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
In this way you get the quick prototyping advantage of the EDSL
without prematurely committing yourself to either an EDSL or DSL
> 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.html
> In fact, in this benchmark, Haskell performance turned out to be
A second data point is xmonad which is often commended for its
responsiveness, in a domain where the competition is using C.
More information about the Haskell-Cafe