[Haskell-cafe] Financial Engineering with Haskell

Joel Reymont joelr1 at gmail.com
Tue Jan 23 17:29:15 EST 2007


This is a subject near and dear to my heart and I also dabble in Lisp  
and Erlang.

Google for "Composing Financial Contracts", you will surely like the  
paper. This is the paper that got me started with Haskell. I'm sure  
you could do financial data mining in either Lisp, Haskell or OCaml.  
I think what matters most is being able to "compose" and specify what  
you want to do as opposed to how.

You could compose your contracts in Lisp but it would not be as  
elegant as in Haskell. You would need to deal with layers and layers  
of macros, wrapping your head around the prefix notation and having  
to add laziness to prevent your data structure from always being  
evaluated. Lastly, you would want to apply different methods to your  
engineered contracts, e.g. to price them or print them as documents.  
There's no pattern matching in Lisp or guards for that matter. This  
means that you would need to resort to lots of imperative code and  
case statements that check the type of the data structure passed in  
to special-process it. Yes, you could add pattern matching to Lisp  
but it's not natural or that elegant. Yes, you could accomplish the  
same goal with CLOS, i.e. objects and methods. You could do the same  
in C++, Python or many other languages.

Haskell is uniquely suitable for financial engineering. The boon of  
Haskell is being able to build a lazy data structure in memory to  
describe your financial contract, then use pattern matching and  
guards to deconstruct this data structure and slice it and dice it as  
you see fit, without having to evaluate it fully and running out of  
memory in doing so. The boon Haskell is being able to do this  
cleanly, elegantly and succinctly, without the need for extra helping  
layers of code.

The bane of Haskell is not being able to predict the performance in  
doing the above. This may not be the reason why Yaron chose to use  
OCaml at Jane St a few years ago but this is certainly the reason why  
anyone would hesitate to use Haskell for the same purpose now.  
Haskell performance optimization is still black art and a few bits of  



More information about the Haskell-Cafe mailing list