[Haskell-cafe] Should I step into a minefield? / Writing a trading studio in Haskell

[Manuel M T Chakravarty]

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.html 
 >  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