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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe