Lambda the Ultimate

What are the limitations of data-oriented and object-oriented approaches for modeling financial instruments?

Data models and object models aiming to encapsulate the definitions and behavior of financial instruments have been developed by banks and vendors in recent years...

Many of these initiatives did not meet expectations mainly because data models and object models are not compositional (See above "What do you mean by compositional?")...

Objects are not compositional???

The combinators from the original paper can be defined as methods on a class Contract and instances of that class, e.g. each of the methods listed below would have a straightforward implementation. The signatures are defined in an "OO" way instead of as functions. Does anyone familiar with an "OO" programming language doubt that these methods could be implemented in that language?

Contract class methods:

#zero "Answer a Contract that may be acquired at any time, has no rights and obligations, and an infinite horizon."

#one: aCurrency "Answer a Contract that immediately pays the holder one unit of currency and an infinite horizon."

Contract instance methods:

#give "Answer a Contract with the rights and obligations of the receiver reversed."

#and: aContract "Answer a Contract such that if a party acquires the result then that party also immediately acquires the receiver (if unexpired) and the argument (if unexpired). The result expires when both the receiver and the argument expire."

#or: aContract "Answer a Contract such that if a party acquires the result then that party must immediately acquire either the receiver or the argument, but not both. If either has expired, that one cannot be acquired. The result expires when both have expired."

#truncate: aDate "Answer a Contract that is like the receiver but expires at the earlier of aDate or the horizon of the receiver."

#then: aContract "Answer a Contract such that if a party aqcuires the result and the receiver has not expired then the party also acquires the receiver. If the receiver has expired then the party acquires the argument. The result expires when both have expired."

#scale: anObservable "Answer a Contract such that if a party acquires the result then the party also acquires the receiver, except that all the rights and obligations are multiplied by the value of the observable at the moment of acquisition."

#get "Answer a Contract such that if the result is acquired then the receiver will be aquired by the same party at the horizon of the receiver."

#anytime "Answer a Contract such that if a party aquires the result at time t, then the same party may acquire the receiver anytime between t and the expiration of the receiver. The result expires at the same time as the receiver."

Well, I did have a crack at implementing the basic Haskell parser combinators in VB.Net a while back. It wasn't impossible by any means, but it was certainly a pain.

A "combinator" in VB.Net was simply a function that took two delegates (method pointers) as parameters and returned a third delegate as a result. Each combinator function had to create a new instance of a class that stored the two input delegates as private members, and exposed a public method containing the logic to combine those delegates. The output delegate was a pointer to that method on the new instance.

If ContractA.compose(ContractB.compose(ContractC))) yields a new Contract object (say ContractD), then how is ContractD's logic actually represented internally, and how is this internal representation constructed? I can see how this syntax can be used to express the composition of objects, but that doesn't tell me how they are *actually* composed...

Yes, I suspect a Java-like language is going to be significantly more cumbersome than a simpler language like Smalltalk, Ruby, or Python.

I'll work up some examples from the contracts paper to see how they compare.

However this can be quite cumbersome. Especially when you need binary methods in a class-based language.

Yes, that's roughly the way I was thinking - that there would have to be some interpreted mini-language under the covers. The obvious advantage of Haskell + combinators, in this case, is that the mini-language is directly embedded - so the interpreter just is the Haskell interpreter (or compiler, as may be).

In my experience, teaching both a PL course and a SE (OO biased) course, the PL students quickly understand how to use these techniques whereas the SE students find this very tricky. [The exercise is to handle a Shape ADT, which is defined by a Point_Inside function, and define Shape addition, intersection etc.].

I am not claiming this to be valid research... The student profiles are different and the sample isn't large enough. But the OO approach is considered puzzling (even after I present the solution) where as the functional approach seems natural to my students in this case.

This of course depends on the syntax of the language, right? i.e. Lisp and Smalltalk incorporate binary operators well, while Python and languages with a C-like syntax are somewhat more awkward.

A zero coupon discount bond for 100 British pounds that expires at time t would be expressed in Smalltalk as...

((Contract one: GBP) truncate: t) get scale: 100

This expression has three binary methods (one more than necessary in the functional combinator case since I made #one: a class method.)

I guess one small advantage of this Smalltalk syntax over the functional combinator syntax of Haskell is that the Smalltalk code reads left to right, which is natural for an English speaking person. The Haskell combinators read right to left. (Just a nit, but I thought it was interesting.)

Consider the #and: method in Smalltalk. Define a class called AndContract. This is a kind of contract that has two instance variables, firstContract and secondContract.

When you send an #and: message to any contract, it does this...

Contract>>and: anotherContract
  "Answer an 'and' contract with self as the first contract
   and the argument as the second."
  ^AndContract first: self second: anotherContract

The result contract is now composed of the reciever and the argument for the two instance variables, firstContract and secondContract.

It seems that we then need a new class (subclass of Contract?) for each way in which a Contract can be combined with another Contract. The result is similar to what I ended up with in VB.Net: in order to bind the functions combined in a combinator, we need a class with two private members (firstContract and secondContract), and a method that expresses the logic by which they are combined. Point taken that this is do-able, although done this way it's actually not much less cumbersome in Smalltalk than in VB.Net.

A preferred (by me) method in Smalltalk, Ruby or Python would be to take advantage of Smalltalk's and Ruby's blocks, and Python's ability to treat functions as __callable__ objects, and have combinator functions (or blocks) that bind functions (or blocks) into closures using lexical scoping. Python example:

def And(aContract, anotherContract):
   def AndContract(args):
      return aContract(anotherContract(args))
   return AndContract

Exactly.

A preferred (by me) method in Smalltalk, Ruby or Python would be to take advantage of Smalltalk's and Ruby's blocks, and Python's ability to treat functions as __callable__ objects

For Smalltalk I think it is cleaner to define composable objects rather than to compose blocks. Python is an interesting mix. I could be swayed toward this approach, especially since the object syntax per se would be nothing to write home about. Ruby... it's been a long time, can't say.

$ 2000 scale 2 libro * ^ £200 or 2006-01-01 when

Which means, $2000 to the power of twice the london interbank rate, or £200 cash, on the first day of 2006.

eg. $ 2000 scale 2 libro * ^ £200 or 2006-01-01 when

$2000 2 libro * ^ £200 or 2006-01-01 when

$2000 (2 * libro) ^ £200 or 2006-01-01 when

$2000^(2*libro) £200 or 2006-01-01 when

£200 or $2000^(2*libro) 2006-01-01 when

At 2006-01-01 either £200 or $2000^(2*libro)

I'm not sure if traders might not prefer the Forth version since it's shorter, and, with practice, harder to misread.