new haskell project (Was Re: [Haskell-cafe] Subtype polymorphism in Haskell)

older
building ghc-6.12.3 from source on...

Simon Courtenage

6 Jul 2010 6 Jul '10

2:26 p.m.

Hi, Just to add some details about the project I'm working on in case anyone is interested. The project is called Quanthas and is being hosted on sourceforge at http://sourceforge.net/projects/quanthas/. The aim of the project is to produce a Haskell implementation of Quantlib ( http://sourceforge.net/projects/quantlib/)- an open source library for quantitative finance written in C++. Haskell is starting to be used seriously in quantitative finance and risk modelling circles within the investment banking and finance community, so I thought there would be some value in producing such a version. If anyone is interested in helping out, we would be more than happy to hear from you, since the project has just started and there's a great deal to do (and learn!). Best regards Simon Courtenage On Tue, Jul 6, 2010 at 2:32 PM, Yitzchak Gale wrote:

...

Hi Simon,

Did you intentionally not reply to the list?

Simon Courtenage wrote:

...
This is for a project to port an open-source C++ library to haskell.

Great! We'd love to give you whatever support you need for your efforts.

...
My initial plan is to more or less preserve the way the library works in the first draft of the port and see how far we can get like that

That's fine, as long as you truly mean the way it works, and not the way the code is structured. Haskell is a post-OO language. Its abstractions are very different than class structures in C++. There is no direct translation - any given C++ class structure could correspond to many totally different kinds of Haskell programs, depending on what the program is trying to do.

If you are trying to find a method to transliterate a strongly OO-style C++ program more or less word for word into Haskell in a way that the class structure of the C++ will still be apparent in the result, you are likely in for a frustrating experience. You will spend a lot more time than you expected, and the results will be very unsatisfying. Many others have ended up that way.

On the other hand, if you are willing to be a little more flexible in your thinking, you'll probably find the task much easier than you thought, enjoy it, and reap many benefits from the process that you never imagined.

In any case, please keep us in the loop, we'd like to hear how it's going. And, uh... would you be willing to share a few more details about what it is that you're trying to port? ;)

Thanks, Yitz

Attachments:

attachment.html (text/html — 3.0 KB)

Show replies by date

Daniel Cook

9 Jul 9 Jul

12:15 p.m.

New subject: new haskell project (Was Re: Subtype polymorphism in Haskell)

Hi Simon, I'm interested in this as well (you might have seen my other posts about getting QuickFIX interfaced with Haskell). One question (Yitzchak raises a valid point): Why port QuantLib's structure rather than directly build an idiomatic Haskell quantitative finance library? Especially given that the task lends itself so nicely to functional programmming (cf the canonical Functional Pearl by SPJ on composing financial contracts). Just curious about your rationale... Cheers, - Dan On Tue, Jul 6, 2010 at 7:26 PM, Simon Courtenage wrote:

...

Hi, Just to add some details about the project I'm working on in case anyone is interested. The project is called Quanthas and is being hosted on sourceforge at http://sourceforge.net/projects/quanthas/. The aim of the project is to produce a Haskell implementation of Quantlib (http://sourceforge.net/projects/quantlib/)- an open source library for quantitative finance written in C++. Haskell is starting to be used seriously in quantitative finance and risk modelling circles within the investment banking and finance community, so I thought there would be some value in producing such a version. If anyone is interested in helping out, we would be more than happy to hear from you, since the project has just started and there's a great deal to do (and learn!). Best regards Simon Courtenage On Tue, Jul 6, 2010 at 2:32 PM, Yitzchak Gale wrote:

...
Hi Simon,

Did you intentionally not reply to the list?

Simon Courtenage wrote:

...
This is for a project to port an open-source C++ library to haskell.

Great! We'd love to give you whatever support you need for your efforts.

...
My initial plan is to more or less preserve the way the library works in the first draft of the port and see how far we can get like that

That's fine, as long as you truly mean the way it works, and not the way the code is structured. Haskell is a post-OO language. Its abstractions are very different than class structures in C++. There is no direct translation - any given C++ class structure could correspond to many totally different kinds of Haskell programs, depending on what the program is trying to do.

If you are trying to find a method to transliterate a strongly OO-style C++ program more or less word for word into Haskell in a way that the class structure of the C++ will still be apparent in the result, you are likely in for a frustrating experience. You will spend a lot more time than you expected, and the results will be very unsatisfying. Many others have ended up that way.

On the other hand, if you are willing to be a little more flexible in your thinking, you'll probably find the task much easier than you thought, enjoy it, and reap many benefits from the process that you never imagined.

In any case, please keep us in the loop, we'd like to hear how it's going. And, uh... would you be willing to share a few more details about what it is that you're trying to port? ;)

Thanks, Yitz

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Simon Courtenage

10 Jul 10 Jul

2:15 p.m.

New subject: new haskell project (Was Re: Subtype polymorphism in Haskell)

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. 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! Regards Simon On Fri, Jul 9, 2010 at 5:15 PM, Daniel Cook wrote:

...

Hi Simon,

I'm interested in this as well (you might have seen my other posts about getting QuickFIX interfaced with Haskell).

One question (Yitzchak raises a valid point):

Why port QuantLib's structure rather than directly build an idiomatic Haskell quantitative finance library? Especially given that the task lends itself so nicely to functional programmming (cf the canonical Functional Pearl by SPJ on composing financial contracts). Just curious about your rationale...

Cheers, - Dan

...
Hi, Just to add some details about the project I'm working on in case anyone is interested. The project is called Quanthas and is being hosted on sourceforge at http://sourceforge.net/projects/quanthas/. The aim of

On Tue, Jul 6, 2010 at 7:26 PM, Simon Courtenage wrote: the

...
project is to produce a Haskell implementation of Quantlib (http://sourceforge.net/projects/quantlib/)- an open source library for quantitative finance written in C++. Haskell is starting to be used seriously in quantitative finance and risk modelling circles within the investment banking and finance community, so I thought there would be some value in producing such a version. If anyone is interested in helping out, we would be more than happy to hear from you, since the project has just started and there's a great deal to do (and learn!). Best regards Simon Courtenage On Tue, Jul 6, 2010 at 2:32 PM, Yitzchak Gale wrote:

...
Hi Simon,

Did you intentionally not reply to the list?

Simon Courtenage wrote:

...
This is for a project to port an open-source C++ library to haskell.

Great! We'd love to give you whatever support you need for your efforts.

...
My initial plan is to more or less preserve the way the library works in the first draft of the port and see how far we can get like that

That's fine, as long as you truly mean the way it works, and not the way the code is structured. Haskell is a post-OO language. Its abstractions are very different than class structures in C++. There is no direct translation - any given C++ class structure could correspond to many totally different kinds of Haskell programs, depending on what the program is trying to do.

If you are trying to find a method to transliterate a strongly OO-style C++ program more or less word for word into Haskell in a way that the class structure of the C++ will still be apparent in the result, you are likely in for a frustrating experience. You will spend a lot more time than you expected, and the results will be very unsatisfying. Many others have ended up that way.

On the other hand, if you are willing to be a little more flexible in your thinking, you'll probably find the task much easier than you thought, enjoy it, and reap many benefits from the process that you never imagined.

In any case, please keep us in the loop, we'd like to hear how it's going. And, uh... would you be willing to share a few more details about what it is that you're trying to port? ;)

Thanks, Yitz

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Edward Kmett

4:43 p.m.

New subject: new haskell project (Was Re: Subtype polymorphism in Haskell)

On Sat, Jul 10, 2010 at 2:15 PM, Simon Courtenage 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

5431

Age (days ago)

5435

Last active (days ago)

List overview

Download

3 comments

3 participants

participants (3)

Daniel Cook
Edward Kmett
Simon Courtenage