Combinator library gets software prize

[C.Reinke]

[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