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

Joel Reymont joelr1 at gmail.com
Wed Nov 7 20:02:56 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 [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.

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.

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.

	Thanks, Joel

[1] http://www.tradestation.com/default_2.shtm
[2] http://www.ninjatrader.com/webnew/index.htm

--
http://wagerlabs.com







More information about the Haskell-Cafe mailing list