Should I step into a minefield? / Writing a trading studio in Haskell

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Should I step into a minefield? / Writing a trading studio in Haskell

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.

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





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Should I step into a minefield? / Writing a trading studio in Haskell

Heinrich Apfelmus
Manuel M T Chakravarty wrote:

> 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 just can't see how laziness can help in processing real-time price data.
>
> 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).

Yes, you definitively want a host language with non-strict semantics for
EDSLs. For instance, custom control structures like

   if' p a b = if p then a else b
   when p m  = if p then m else return ()

loose lots of their usefulness in a strict language. Same for parser
combinators, since you can't even define

   many :: Parser a -> Parser [a]
   many p = empty ||| (liftM2 (:) p (many p))

(Sooner or later, you probably want observable sharing for such
recursive values, but that's another story.)


In any case, the problem of choosing a host language and achieving good
user experience is probably negligible compared to the difficulty of
designing a powerful trading DSL in the first place :)


Regards,
apfelmus

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe