On Sat, Jul 10, 2010 at 2:15 PM, Simon Courtenage <courtenage at gmail.com>wrote:
> Hi Daniel,
>> 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.
>> 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.
>> 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.
>
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.
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:
http://conal.net/blog/posts/sequences-streams-and-segments/
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.
> 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!
>
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.
-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100710/a43e022d/attachment.html