Wadler's Blog

I think the 'multiple python implementations' problem is simply solved by blessing a cpython version as the official one.

I would hope, however, that the definitions, in whichever language, would use at least high-precision decimal floating point. Arbitrary precision would be even better to eliminate any machine to machine differences (even those allowed within the IEEE floating point spec would lead to confusion).
 

In what way will a Python script provide clearer semantics than the standard legal descriptions of trades? The semantics could only be defined by mandating a specific version (and possibly machine platform) for Python. As just one example, small differences in floating point behaviour matter.

Passing executable code around in financial trades - is that not a prime vector for viruses and malware? Better to have declarative code that could be analysed rather than executed.

What financial firm will be willing to release exact pricing information in any programming language? This is highly sensitive commercially - if available to customers and competitors, it would open up a huge new possibilities for betting against firms.
 

I posted to LtU, this is a cross-post. I didn't read the proposal.

I find it strange, but I do not understand what it is they're after, so, working from gut feeling, my view. My first reaction on the assumption that they wanted to formalize contracts and actually use it, the solution should have been:

XML, DTDs, C/C++/C#/Java, and a full blown requirements/design document
It's the most industrial accepted solution which will integrate the best with most software packages.

Good:
1. Best integration with tools
2. Req/design documents gives portable implementations
3. One industrial format for contracts

Bad:
1. One industrial format for contracts
2. Very slow development cycle
3. Poor capability for interesting hacks (excluding a C# implementation)
4. Good chance of getting it wrong
5. Very static, needs an embedded DSL

Python
So, the reasons for Python seem pretty odd. I really don't see the reason for executable specifications? To add reasons why, and why not. On the good side:

1. OO so (good) design
2. User friendly concise readable syntax (even for non-programmers)
3. Easy to hack, the development cycle is extremely short with their interactive debugger
4. Untyped dynamic prototyping makes all kinds of interesting light-weight hacks possible
5. Lots of librarries
6. Refactoring in hours instead of days
7. Prototyping for fast requirements engineering, may give a spec

On the flip side:
1. No type-safety. Expect run-time/logical errors
2. No value-safety. Expect integers and strings where you'ld expect reals or floats. Calculations will go wrong unnoticed. (This is a real show-stopper for me)
3. High likelihood of errors through indentation mistakes
4. Poor integration with industrial tools
5. Performance issues

Haskell
And, as an addendum, reasons for Haskell, and not:

1. FP so once specified, no real reason to expect logical errors
2. Interactive environment, can be used for scripting
3. Gives a formal specification

Reasons against:
1. Even with an expected easy problem domain, slow development cycle
2. Takes ages to hack new applications, poor integration with other tools
3. Unreadable for people not used to FP, that includes the formal spec
4. A possible shortage of programmers
5. Academic, no support, may die in five years

Hmm, all-in-all, except for the poor integration, and value-safety, Python isn't even a bad choice as a prototyping tool.
 

SIGPLAN should be neither an advocate nor detractor of any programming language. SIGPLAN's charter states:

"...SIGPLAN explores the design, implementation, theory, and efficient use of programming languages and associated tools." It is not an advocacy group.

It would be proper for SIGPLAN to put forth some considerations to keep in mind for an organization endeavoring to adopt a programming language for some purpose, but to suggest one or to recommend against another would seem to me to drop SIGPLAN (and by implication, ACM) into the realm of politics, or perhaps propaganda. That is, SIGPLAN should teach and little else in matters like this.
 

I updated some more reasons on LtU, if it should be formalized, then preferably in XML with a DTD and a formal spec. Python is too much a moving target, so is Haskell. Whether or not financial firms want to give pricing information is beyond SIGPLAN.

Defining a simple language (in XML, or human readable XML) is easy. It can be close to Python, a conforming specification could be written in Haskell, but industry is best served with an industrial standard, if politics demands that.

Demanding decimal fixed-point makes sense.
 

"It has been proposed that SIGPLAN file a response to the SEC's request for comments." Ah, the convenience of the passive voice, evading mention of just who has proposed this.

Even if it were in the charter of SIGPLAN to address this sort of issue and to advocate for particular solutions (see the post by rpg arguing the contrary), one might ask why the United States Securities and Exchange Commission, a US federal agency, should pay primary attention to the advocacy of an international organization. From their perspective, it seems to me that they would want to get their advice on this topic, if any, from the US National Academy of Engineering, whose charter is (unlike that of SIGPLAN) explicitly to serve as an advisor to the US federal government on engineering matters, such as the choice of a programming language for any specific purpose.
 

Er..., how about a language that has a formal definition? SML comes to my mind.
 

Thanks for your comment, Guy. Apologies for the passive voice. Various folk wrote to me, but I'm happy to own up that I think a response from SIGPLAN is a good idea.

Dick Gabriel makes an excellent point. I think it is important that any reply from SIGPLAN enjoy the support of the community. Any draft reply will be posted for further comment by the community before it goes out.

I am not suggesting SIGPLAN should reply by saying 'ditch Python and use a functional language'. Current thinking for a reply (but more thoughts are coming in) is along the lines: 'We welcome this initiative. There is considerable work on modelling finances in functional languages, and the SEC should ensure financial institutions can build on this work.' One concern I have is how to open the door to solutions that are better than Python without opening the door to solutions that are worse. I would welcome comments pointing out the ways in which Python is well suited for this task, particularly if people know of uses of Python related to this sort of modelling.

If the premier organization of the programming language community doesn't have a role in replying to this, then something is seriously wrong. But it would also be wrong if the reply represented only a small subset of the community. Please help me to ensure that our reply is representative.

Yours, -- P
 

After some back-and-forth by email, I think Phil and I have converged, if not to agreement, then at least to a mutual understanding of each other's positions and goals. For the record, I quote here from my last email:

[Your points are] well taken. Nevertheless, I remain leery of SIGPLAN, as an organization, taking any stand on its
own stick much beyond "Here are some languages or papers you should
look at."

You asked for the views of the programming language community.
I count myself a member. You now have my view. :-)

I emphasize that I do not differ with you on whether a message
should be sent to the SEC, nor do I (yet! :-) differ with you on what
the content of that message should be. My argument concerns only
the propriety of process and roles within that process.

At the very least, let me suggest that it would be appropriate for
SIGPLAN to work with the ACM Public Policy Office and/or USACM before
issuing comment, and perhaps any comment should be issued through
one of those ACM suborganizations. See http://www.acm.org/public-policy .
 

Thanks to Guy for his comments. SIGPLAN and US ACM now plan to make a joint submission. Let me know if you are interested in serving on the joint task force.
 

ISDA is the trade association that writes the standard contracts used for OTC derivatives. These contracts are available in two forms:
1. As English prose templates with spaces to fill in the parameters for each derivatives contract.
2. As XML Schema in FpML.

The electronic (XML Schema) version of each derivatives contract is drafted alongside the natural language (English) version of each derivatives contract. Through experience it was found that structural modelling was akin to legal drafting.

Michael Will, of the bank's lawyers Allen & Overy, is a good example of a lawyer who groks this, moving from one side to the other.

Derivatives contracts contain many dependent types. These are difficult to express in XML Schema, so the solution in FpML was to use sibling invariant constraints. These FpML constraints needed to be precise and complete but not necessarily formal - in that they had to have formal semantics behind them to avoid ambiguity but you didn't need to be able to reason about them. The language chosen was XPath2/XQuery, which has formal semantics. One of the authors of the XQuery formal semantics was Phil Wadler.

Using XQuery it is possible to specify the payment amounts and dates. The addition of higher order functions to XQuery is making this much simpler.

However there are practical issues where we lack meta-circularity:
1. The XPath/XQuery formal semantics don't cover the entire language, so they're not complete.
2. The mathematical notation used in formal semantics is itself not formally defined. Logic notation in particular has moved quickly and informally.
3. Laywers and Judges come from a different culture and may well interpret negative numbers as zero, zero as nothing, and so on. This is why you don't get negative or zero numbers in OTC contracts.

In practise formal semantics is not enough, you also need to define the pragmatics. What does it mean to register the same asset with new details - does it replace, update, depend upon some other flag? There is active research on formal pragmatics, but in no way is it solid enough to use in industry yet.