[oops, somehow this ended up in my drafts folder, not on the list; sorry for the delay] First, to avoid confusion: I'm not criticising the work described. I'm just pointing out that, in my view, the major advantages of functional programming lie beyond what is used in this application (in other words, there is yet more to be gained, and we should not underestimate the role of the facilities imported from the functional host language, such as functional abstraction). [one quibble: I don't like the idea of using floating point numbers to represent real money without further comments. Even after avoiding representation error surprises by using base10 instead of binary floating points, aren't there precise standards for rounding in the financial market? Or have I missed an explanation of this in the paper?]
Am I the only one who finds the exclusive emphasis on combinator languages slightly disappointing (in fact, the article seems to equate functional language with domain-specific combinator languages, which is more than a bit mistleading)?
What declarative approach(es) (other than combinators) are you referring to here?
Mostly lambda-calculus; more generally, all approaches that deal explicitly with variables and variable binding, and the resulting languages, which are general enough that DSLs for many domains can be embedded in them. Even within combinator languages, I am not always sure whether those reporting on the paper are aware how much the DSL gains by being embedded in a full functional language, and how simply exporting the core DSL to another context would severe all those useful connections. In the present context, most of the excitement seems to focus on the contract combinators, because they bring a new approach towards order in the application domain. They can be viewed as a first-order functional language on contracts. This core part of the DSL could be used in other modern languages as well, provided their expression sub-language is sufficiently expressive (although the syntax, e.g., new And(..) and new Give(..) in Java, or <Give>..</Give> in other contexts, would quite likely annoy the user). But the paper goes beyond that, e.g., it defines and uses some higher-order features for observables. Also, functional programmers will be tempted to use partially applied contract combinators in higher-order compositions (as a simple example, take "all = foldr and zero :: [Contract] -> Contract" -- acquiring "all contracts" acquires a list of contracts). Such uses are already slightly more difficult (and typically much more ugly) in non-functional languages, so simply providing the same basic DSL as a library embedded in a non-functional language will not necessarily give the same flexibility (and a dedicated implementation of the DSL would have to decide between supporting only simple uses of the combinators or adding some more advanced features). Of course, in addition to combinators, we also need definitions, so that we can give names to useful combinations of combinators. This comes for free if the DSL is embedded in Haskell, but if we take it out of this context, we need to start thinking about what kind of definitions we can or want to support: parameters? certainly. what types of parameters? what types of things can be defined? how are parameters passed?.. And suddenly, we're into the definition and implementation of a little (higher-order?) functional language, with support for functional abstraction (how much support?). Does the host language (or the dedicated implementation) support all the things we want in the way we expect? In any case, the core contract combinator DSL doesn't stand in isolation - we need to work with the contracts, operate on dates, evaluate options, iterate through sequences or alternatives, .. Do we do this in functional style, or by shouting imperatives at those poor contract combinations?
The consequence (and the intention, as far as one can gather from the paper) of the limitation to combinators is that this language can and will be used mainly in non-functional languages, not inheriting all that much from a functional style of programming. The same will probably hold for any communication standards based on it.
Why is that? I'm new to the functional programming world, and haven't reallystruck the concept of combinator libraries elsewhere. I assumed they were largely a functional programming concept. Even though I can see how they could be implemented in imperative languages, it doesn't seem that they would be a nice fit.
That's my point. But so far, I don't see any external commitment to a functional host language for the core combinators. Of course, that impression could well be wrong.. The paper suggests the Haskell implementation as a prototype to help the development of an existing C++ implementation as well as a new implementation in OCaml (implementation language, not host language). Most positive external comments seem to focus on the core contract combinators as a possible means to standardize the way professionals and software are talking about contracts (XML-like). Now, if you cut out the contract combinators from the DSL embedded in Haskell and try to find something that can be used across C++,OCaml,XML-processing Java, etc., you might end up writing for-loops, assigning contract combinations to global variables, sending messages to contract objects, and all the other funny non-functional things that are so happily used outside the Haskell world.
[Several interesting elided]
More generally, is there any more information or forums on declarative approaches to financial engineering? I found this paper intriguing, as it focuses on both my current academic interests, and my work!
I'm not an expert in this area, but from the few references in the paper, it seems that there hasn't been much work, and from the comments on the paper, it seems there there is a growing interest. Perhaps there are enough people interested now to warrant setting up such a forum. Claus