<br><br><div class="gmail_quote">On Sat, Jul 10, 2010 at 2:15 PM, Simon Courtenage <span dir="ltr"><<a href="mailto:courtenage@gmail.com">courtenage@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Daniel,<div><br></div><div>Thanks for getting in touch - I would recommend, if you are interested in the project, that you join the project mailing lists, and let me know your sourceforge account name so I can add you to the project membership list.</div>
<div><br></div><div>About the design question that you raise. The aim is to create a version of Quantlib in haskell in the sense that what is available in Quantlib is available in the Haskell version - for example, to create pricing engines and apply them to products. No-one currently involved on the project - certainly not me - is such an expert on quantitative finance that we could do this from scratch. In fact, I hope to learn a lot about this subject as a result of doing the project.</div>
<div><br></div><div>In addition, since Quantlib has already a large user base that is used to the way components are composed together to get things done, I thought it would be useful to allow similar components to be composed (functionally, of course) in a similar way to allow knowledge about the one to be used with the other.</div>
</blockquote><div><br></div><div>I've taken a fairly in-depth look at QuantLib. I think a 'direct port' would yield a fairly unnatural API from the perspective of Haskell. The basic QuantLib model is fairly mutation oriented. However, I think there is a kernel of it that can port fairly naturally. </div>
<div><br></div><div>The first step in deriving something idiomatic would be figuring out how to make it work nicer in a persistent setting without mutation to get something that feels like a Haskell library. i.e. net present value calculations needs access to when 'now' is, so with some work that whole framework could be shifted to use a reader monad capturing the current time, and laziness or even memoization can be used to avoid heavy recomputation. Another option is to make NPV work in relative time. This shift in perspective would yield something like:</div>
<div><br></div><div><a href="http://conal.net/blog/posts/sequences-streams-and-segments/">http://conal.net/blog/posts/sequences-streams-and-segments/</a></div><div><br></div><div>The second shift in thinking is that I think most of what you are looking for in subtyping can be had readily enough by switching your view of classes around. Instrument works perfectly fine as a Haskell class and any time you need to box them up and work with a bunch of different financial instruments the same way, you can repackage them as functions, or use an existential container that can, at worst, give you access to Dynamic/Typeable to special case the handling of particular instruments.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Quantlib, therefore, provides a knowledge-base and reference architecture for the new haskell project. My (naive) idea, at the beginning, for all these reasons, was to follow and be guided by, but not faithfully recreate or replicate, the structure of the C++ code. I'm open to new ideas about design, and anyone who wishes to contribute is more than welcome to join the project!<br>
</div></blockquote><div><br></div><div>There are a number of places where it would be fairly trivial to improve upon the design of quantlib due to the ease of overloading and polymorphic instantiation in Haskell, e.g. dealing with portfolios that span multiple currencies, so take care with shackling yourself to the current design.</div>
<div><br></div><div>-Edward Kmett</div></div>