Rollover Talk is an open-source computer programming language designed and implemented by Rollover Technologies for use across its products and systems. It is intended for use both internally, as a bridge between and among low- and medium-level daemons, and externally, as a tool for execution of user programs. Our language is based on a major dialect of Lisp called Scheme, which is known for its rigorous formal definition and powerful, compact expressiveness. In basing our language on Scheme, we draw on a decades-long tradition of computer language research and development, including seminal work on dynamic systems and optimization.
If all programming languages were equally useful, there would be only one. Since languages are designed with different goals in mind, however, it follows that each language has particular strengths and weaknesses. Rollover Talk has many features which make it supremely appropriate for our purposes, and no important weaknesses.
Using Rollover Talk, it is possible to integrate new programs into a constantly-running programmatic ecology. Not only may new programs be introduced to the environment without requiring everything to be stopped and restarted, but old programs may be replaced as well while the rest of the system continues to function. The technical term for this is a "dynamic environment". This is important in high-reliability, constantly-running services such as those which we provide, especially since we integrate large portions of customer-originated code into our systems.
Another feature useful in maintaining high reliability is the ability of the system to keep errors in faulty user programs from causing malfunctions in correct programs. This is related to the fact that the environment is dynamic, but is important enough to point out separately. This is also the same basic feature which allows us to ensure that users do not accidentally or maliciously gain access to each others' data or programs.
Because we have designed and implemented the language ourselves, we understand it very well and can easily make modifications and optimizations as needs arise. The language is naturally lean and efficient, with small programs able to express complex and useful functionality. We have written it for extreme portability, and therefore our systems are agile with respect to architecture, enabling us to choose the most advantageous computational platform with a minimum of switching cost. Furthermore, this approach has given us the ability to integrate the necessary data-security measures into the lowest level of the execution environment.
Lisp-derived languages such as Rollover Talk share the property of unity between program and data. This is important to us because by putting Rollover Talk "on the wire", we can communicate complex behavior back and forth between various independent services within our larger system. This aspect of the language is expanded upon below in the section Communication Using Rollover Talk.
Expressions may be nested. "(+ 3 (* 2 2))" obtains the same result as the previous example, but does so by first evaluating the sub-expression "(* 2 2)" to multiply 2 by 2, then using that result as an argument to the outer function.
The crowning glory of the language's Scheme-based semantics, however, is its concept of the first-class function as data. Function objects are called "lambdas", and allow for much of Rollover Talk's expressive richness. Although too complicated to explain here in detail, by allowing functions to be constructed on the fly and passed as data, the language attains a brevity of expression and ease of functionality as yet unmatched.
In addition to the essentials which any reasonably-complete programming language must have, Rollover Talk has been specialized with functionality specific to trading. It does not matter whether the object of a trade is a financial instrument or a rare pair of shoes: Rollover Talk allows interaction with the market. Although a full description of the language features is beyond the scope of this document, functions are available to deal with a wide range of interesting financial issues, including but not limited to:
To briefly give the reader a feel for the expressive and powerful nature of the system, the "open-order" function will be described here in minimal detail. This function allows users to enter buy and sell orders into the system.
Let us suppose that a Rollover Talk user wishes to write a program to purchase 500 shares in the Balinese National Gamelan. The user would write a Rollover Talk expression like this:
(open-order 'purple 'ORCH.BNG 500 'partial-ok 'market (days 2))This will appear strange if one is not familiar with the Lisp-derived syntax, so please bear with the description. The meaning of each of the elements in the above is as follows:
| open-order | the function name indicating what operation is to be performed. In this case, a new order to buy or sell is being entered into the system. |
| 'purple | a reference symbol. This could be any valid Rollover Talk object, and since it will be retained by the system as part of the order, it may be used by the user as a programming aid to reference the user's own data. |
| 'ORCH.BNG | the name of the instrument to be traded. In this case, the symbol represents shares in the Balinese National Gamelan, traded via the Orchestra Market. If the symbol instead were 'NASDAQ.AAPL, that would represent shares in Apple Computer, traded via NASDAQ. |
| 500 | the number of shares to be traded. Since the number is positive, this order represents a purchase. |
| 'partial-ok | indicates that if the full number of shares (in this case, 500) cannot be purchased, the order should still be executed. |
| 'market | indicates that the offer to buy is at market price. For a limit order, this would instead be the limit price, in the currency units of the market. |
| (days 2) | a Rollover Talk expression indicating how long the order should be left in the market, unfilled, before it is cancelled. |
We have used Rollover Talk as a data format for communications between various internal services within the Rollover Technologies framework. This results in the considerable advantage that the individual parts of our system may be kept simple--focused upon the very basics which are necessary to providing an individual service--and yet each service is essentially "scriptable" because of its ability to understand Rollover Talk.
For example, we have a user-portfolio daemon which is in charge of maintaining the list of items controlled by each user. When a user executes the 'open-order function described above, the new order is transmitted to the user-portfolio daemon. Subsequently, this daemon interacts with a trading daemon which is responsible for actually obtaining the commodity in question on behalf of the user.
The trading daemon does not inherently need to care about time. Although it is charged with executing trades as soon as possible, this is more akin to an "eternal now" than anything having to do with our quotidian concepts of reality. Such concepts of time do not need to be built-in to the low-level routines of the trading daemon, and this makes the daemon more robust, easier to write, and easier to maintain and to debug.
However, time can be an important part of a financial transaction. A user may not want his trade to execute on Mondays, for example.
Because Rollover Talk is understood by all semantically-distinct parts of the Rollover Technologies system, and Rollover Talk is capable of expressing ideas about time, users can provide such expressions where necessary by means of Rollover Talk. Not only does this free the trading daemon from having to know specifically about time, but it allows it to cope with the discovery of new important concepts. In other words, it does not need to be rebuilt or redesigned each time something about the system changes, or every time it is desired that a new capability be added to the system.