My interest was Domain Specific Languages (DSLs) for financial engineering. In order to develop the necessary vocabulary, I read three articles on DSLs in general ; then read articles specifically about financial ones. The financial DSLs were used for

1. charting patterns of price history ,
2. characterizing contracts and generating present values for contracts involving interest or exchange rates and,
3. characterizing interest products.

In order to understand some of the implementation issues, I read , which outlines several models for describing financial situations that are dependent on interest or currency exchange rates. Table 1 summarizes the differences and similarities among the DSLs as described in the literature. All of the papers I read are summarized in Table 2. Note that cites discuss the same DSL, Risla.

1. Observations

CPL and Contract Composer are embedded DSLs, which means that they were built on top of an existing base language, while Risla is new, special purpose language for which a compiler was built. Interestingly, during the pilot study for the Risla project, a parallel effort was made to use Process Specification Formalism (PSF), an existing language, to model the financial instruments. At the end of the pilot period, it was decided to abandon the use of PSF because its primary strength, the description of processes, was not used on the products. This may offer guidance in the selection of the language to use when designing embedded DSLs in the sense that the general purpose language underlying the DSL has to be general purpose enough.

CPL and Contract Composer appeared to be envisioned as desktop tools for financial forecasters, while Risla was intended to created contract models to be shared by all of a bank's (Bank MeesPierson) information resources. Banks, which are capitalized by savers, are much more regulated (at least until recently) than financial organizations capitalized by investors. This factor may have influenced the design of Risla; that is, the fact that the Risla output would have to drive existing, validated code may have given the bank confidence that the new code could be integrated incrementally, thus allowing them to creep into the water rather than dive in.

I found it interesting that the three efforts came to their tasks with varying amounts of specification done for them:

• The Contract Composer team had no specifications in hand.
• The Risla team had a partial specification written when they started, and had additional information (or constraints) in the form of the existing COBOL code that had to be reused.
• The CPL team had virtually all their specification done for them by the financial community: *all* their primitives, both indicators and patterns, have been defined for years.

The intriguing thing is that, based on what they said in the papers, the Contract Composer group thought that specification was one of the hardest parts of the job, while the CPL team didn't even think about it. And the Contract Composer customer said that not having a common language was the "bane of their existence", while the CPL primitives have been defined in the daily newspaper forever. The Risla team appeared to think that specification was straightforward, but offered an opportunity for discussion with the users. One of the criteria for selecting an appropriate problem for DSLs is a mature domain. Perhaps one of the ways you can tell if a domain is mature if a common understanding of jargon exists.

The Contract Composer developers noted the enthusiasm from the user community for the clarity of the expression provided by the language; it finally allowed them to use clearly defined terms for discussing financial vehicles. This reaction was also mentioned by Hudak , and was mentioned by one of the implementers of Risla (van Deursen) as a reason for DSLs in a survey paper he co-authored. As Anthony Hall said in "Seven Myths About Formal Methods": " . . . the fact is that formal methods are all about specification."

However, in their description of Risla in [2] the authors stated specifically they felt a need to make the language more "accessible" to the financial experts, which implies that the clarity of their implementation might not have been what they had hoped. This might have been a side effect of the decision to interface the Risla product with the existing COBOL products - if the syntax was compromised to support the interface, confusion would result. Alternately, Risla does not appear to be a declarative language - possibly the simple construction of combinators and functions in declarative languages is a better match with user views of their data.

CPL and Contract Composer both used the lazy evaluation capabilities of Haskell, CPL for searching through lists of data points, and Contract Composer for evaluating present value for complex contracts. The authors of CPL appear to believe that implementation in a language with lazy evaluation is much to their advantage. The Contract Composer team recognized the value of lazy evaluation in their prototype, but felt that the production version of this prototype could be implemented in a language without it.

1. Problems and Achievements

There don't seem to be any truly basic problems in this area - even the Contract Composer team, who took on the least defined task, ended up being very successful and continuing their work for corporations who specialize in assessing financial risk. The stumbling block appears to be making the connections between people comfortable with declarative languages and people comfortable with financial instruments.

The papers I reviewed took two approaches to implementing the DSL: starting from scratch (Risla) and embedding the application in Haskell. The embedded approach seemed to be the most straightforward approach, both in resulting ease of expression and during development, although that might be due to the fact that the Risla product actually had to work in a strictly regulated environment.

The main achievement of DSLs in financial engineering have been to demonstrate the expressive ability of little languages for problems of the financial community. At this point, DSLs can't be said to have penetrated the financial world, but they have demonstrated that they can be useful.

2. Future Work

Based on these articles, work has to be done to

• understand how to integrate financial DSLs into legacy software and business processes,
• develop stochastic processes to underpin the interest/exchange rate calculations,
• investigate if there is a "normal form" for contracts.
• the CPL team defined and used two of Allen's calculus of time interval operators. The authors feel that more operators should be defined and used.

1. Papers Read

Table 2 - Summary of Papers Read

Note: Articles marked with * were the primary targets of this paper and are discussed in more detail below Table 2. The rest were read as context.

Title	Content
*Charting Patterns on Price History	Describes Chart Pattern Language (CPL), a Domain Specific Language embedded in Haskell. CPL is used for describing, then extracting, visually detectable patterns from financial charts - bar graphs that show financial activity over a selectable period of time. The extraction criteria are time span, the primitive or composed pattern selected, and (possibly fuzzy) constraints on the pattern definition. Primitives are defined for both financial indicators and chart patterns, new operators and type classes are described, and examples of composing patterns are given. A syntax for CPL and a data type for Pattern are developed.
*Composing contracts: an adventure in financial engineering	Describes a Domain Specific Language for describing contract obligations and privileges and calculating the risks involved in them over time. Primitives for contract definition primitives are provided and a set of "primitive" combinators are developed to describe most contracts. Finally, a set of functions are developed that take a contract map it to a process that can report its value at any point in time. Definitions of the primitives, syntax and evaluation semantics are included. As described in the article, the language was embedded in Haskell, but the authors believe that it could be implemented as efficiently in other general purpose languages.
*An Algebraic Specification of a Language for Describing Financial Products	This article describes the development of Risla, a language for working with interest rate-based products in a banking environment. Risla is used to define products, each of which have functions associated with them that compute the financial effects of the product. The Risla products are then translated into COBOL for use with the existing modules.
Building Domain-Specific Embedded Languages	Describes the goal Domain Specific Language (DSL) as "the ultimate abstraction", which should " . . . capture precisely the semantics of the application domain - no more, no less." Hudak takes the position that it is more efficient to design domain-specific embedded languages (DSEL) - that is, languages that use an existing language as a foundation, and develop a little language on that foundation. Examples of DSELs developed using Haskell are given. Part of the value of DSELs is stated to be their semantic clarity, which makes them easy to understand for domain experts and relatively easy to reason about. He also discusses modular monadic interpreters and instrumenting the DSELs.
Design of High Performance Financial Modeling Environment	The purpose of the paper is to show how the evaluation of various financial instruments can be accomplished using several different techniques and models. The authors investigate a Problem Solving Environment (PSE) to support the manipulation of stochastic processes (appropriate to financial applications), the transformation of stochastic processes to deterministic Partial Differential Equations, and the numerical solution of stochastic problems. This paper provided a laundry list of mathematical tools and techniques commonly used in dealing with financial instruments. While not directly applicable to the topic of this paper, it did describe some of the possible models mentioned in .
Domain-Specific Languages versus Object-Oriented udy	This article nominally contrasts a Domain Specific Language (DSL) with an Object-Oriented Framework designed to perform essentially the same tasks in the financial engineering domain. The DSL was Risla, described in , and the Object-Oriented Framework was the ET++ SwapsManager. Although the ET++ SwapsManager did, in fact, work with cash flow instruments, the intent of the development was entirely different: it was a pilot project to investigate the use of advanced software technologies in the banking industry. As a result, no actual comparisons were developed in the paper - there was high level philosophizing about the appropriate use of each and how they could be used together. This was not a useful paper for my purposes.
Domain-Specific Languages	This is primarily a bibliography of DSL literature, with 78 entries in the bibliography. The bibliography is preceded by a short introduction to DSLs: terminology, risks and opportunities, examples, design methodologies, implementation of a DSL design. Each of the sections has citations for applicable literature, although not all bibliography ntries were specifically cited in the article.
Little Language, Little Maintenance?	Defines little languages as DSLs and describes the development of Risla, a DSL for use in the financial engineering domain - cash flow modeling for a bank, centered on interest rate. The development is motivated by the long lead for introduction new financial products and the difficulty of validating software developed using traditional general purpose languages due to the differences in the semantics between the financial and software domains. A library of COBOL operations existed that operated correctly on financial instruments, but working with them was awkward. Risla describes interest rate-centered products, such as loans and bonds, through use of built in data types for representing entities of interest such as cash flows and time. Operations are also defined, corresponding to operations available in the existing COBOL library. Risla products are translated to COBOL for ultimate use. Unlike the other DSLs built, this paper stated that the domain experts had a difficult time understanding the language and ended up building an interactive user interface for the Risla library. In addition, the paper outlines risks, advantages, and disadvantages of using DSLs, and describes a development environment that may mitigate some of the identified risks.

2. "Composing Contracts, an adventure in financial engineering"

This paper describes an effort that resulted in the development of a library of Haskell combinators for describing financial instruments and assessing risk when investing in them. A set of primitives were defined, and denotational semantics were developed for reasoning about the accuracy of resulting combinators.

The contract primitives were modeled as value processes incorporating random variables to model risk and variability over time. Translation functions are provided to move between single-valued contract primitives (included time-varying observables) and processes manipulating random variables to describe the possible values of the process at some future time t. The "lattice" or "recombining tree" model is used to model the time-varying aspect of contract value, both interest and exchange rates and values of contracts.

The authors derived a set of compositional evaluation semantics in order to reason about contracts. I was struck that you could reason so closely about contracts in the same way that we reasoned about fundamentals of computer languages - contracts, in my experience, have been squirmy things. Out of curiosity, I tried to use their semantics to disprove a proposed equivalence (give (c1 'or' c2) = give c1 'or' give c2) and successfully disproved it. (In the paper, it was stated that the equivalence did NOT exist.) The proof and the necessary parts of the semantics are included as Section 6- not essential reading, but it's there.

Lazy evaluation was valuable because, even with the lattice model, the process trees can get really large really fast. Further, since the whole idea is to allow combinations of various contracts, the combined process tree could be huge - so anything that limits the evaluations is good.

The primary value in this effort may be the precise definition of the primitives; once defined, the whole community can use the same language, with a precise meaning to discuss concepts. The authors state, in addition, that their Haskell implementation can already evaluate contracts that a imperative language risk-assessment program specifically built for that purpose cannot, since the imperative program must be programmed on a case-by-case basis. Further, they felt that the use of a declarative language for describing the contracts was a huge advantage in the initial stages of understanding the domain.

3. "Charting Patterns on Price History"

This paper describes a DSL called Chart Pattern Language (CPL) designed to allow searches through financial charts and extract human-visually detectable patterns. In addition to identifying the patterns, the language allows the use of fuzzy constraints when defining the patterns to be extracted. Finally, über-patterns can be built up compositionally from six primitive patterns. The goals in designing the language were to allow

1. search of large amounts of data reasonably quickly,
2. softening of the constraints of pattern definitions to allow for individual interpretations
3. creation of new patterns, or changing constraints on existing ones.

The language is embedded in Haskell and uses a library of combinators to define patterns.

Each day's trading for a financial commodity is characterized by high, low, opening and closing prices; and volume for the day. On a financial chart, each day is represented by a vertical bar, so a day is called a bar. An indicator type is defined by a function that takes a bar and returns a value. There are five primitive indicator types: high, low, open, close (price indicators), volume (volume indicator). Other indicators can be constructed from the primitives:

move :: Indicator Price move = (high - low)

To inject time into calculations, a combinator called # is defined which allows relative indexing into past days. The form indicator # n results in a list of indicator values for the previous n days. Since use of the # combinator could result in attempts to access days before the history starts, the Maybe type was defined:

data Maybe a = Nothing | a, where Nothing means that an error has occurred

After the authors demonstrate the extensability of their Indicator primitives, they define six Pattern primitives, consisting of one primitive representing a single day, with the rest represented by line segments stretching over several days. Landmarks, the anchor points of patterns, are used to define all the patterns. For the single day indicator, only one point is required; for the line segments, two points are necessary: start and end. A landmarks function (lms) is defined, which takes in an instance of a Pattern and returns its landmarks.

To allow the analyst to filter the patterns, a new operator is introduced: ⋈. The ⋈ operator indicates that a constraint follows. For example, an outside day is one day when the low is lower than the previous day and the high is higher. The following would define that pattern:

To allow the insertion of "soft" constraints, class ToFuzzy is defined, which consists of the types that can be converted to fuzzy values. When it is desired to use fuzzy values for constraints, the FuzzyOrd operators are used: ( ≺ ), ( ≻), ( ≍ ). A function is included to calculate fuzzy values and a default value is normally used as a "seed" when calculate them. Users can change the default if desired.

Two compositions themes are allowed, each with an operator. The followed-by operator (>>) concatenates two patterns if the rightmost landmark of a specified pattern matches exactly with the leftmost landmark of a following specified pattern. The overlay operator (⋄) creates a composite pattern when two patterns are in the exact same time period, that is their rightmost landmarks match and their leftmost landmarks match. Both operators are associative. Ordering is defined for the overlay operator, so that pattern instances of the same pattern can be identified.

Lazy evaluation of Haskell is used in the implementation to avoid evaluation of impossible pairs of patterns, for example, pairs in a followed-by pattern where the second pattern instance starts before the first ends. Through lazy evaluation, this pair will never be calculated.

1. "An Algebraic Specification of a Language for Describing Financial Products"

This paper describes Risla, a DSL for application in a banking environment. The central abstraction in the DSL is the product, which is the Risla description of a financial instrument. Each product is characterized by a set of functions used to calculate the cash flows generated by the product over some time interval, or at some specific time. The Risla description of the product is used to generate COBOL code, which interfaces with the rest of the bank's Information Systems. Algebraic specification was used for the development of Risla, and the ASF+SDF tool was used. A context-free grammar was developed for it and parts were included in the article. Based on searches of bibliography citations, a full specification has not been published in the open literature.

The cash flow is the primary data type in Risla. It is defined as a time ordered list of <amount,date> pairs, which indicates an amount of money entering or leaving the bank on that date. An algebra of cash flows was specified, including addition, subtraction, merging, etc. Balances are another important data type. A balance pair <amount, interval> specifies an amount of money the institution will have available to it over a certain time period. Lists of balances will show all the resources the bank has at its disposal. Products are defined by Risla descriptions and consist of a name and a list of functions that operate on initial product values to compute resultant cash flow.

2. Short Proof Using Contract Composer Semantics

The semantics used are

give :: Contract } Contract - a primitive that means that you have issued a contract and acquired all of contract's obligations as rewards and all its rewards as obligations. That is, if contract c requires disbursing a payment at some time, if you give c, you must make the payment. Also, if contract c states that money must be received, you get the money. Essentially this means that if someone buys a contract, it must have been purchased from a seller, and the seller and the buyer have mirror image obligations and rewards with respect to each other.

Valuation semantic: é _k² give c³ = -é _k² c³

or:: Contract } Contract } Contract - you are offered a choice between two contracts and you must immediately acquire one, but not both. You cannot acquire a contract whose expiration date has passed. The or primitive returns the contract with the maximum value. A constraint is that at least one of the contracts' acquisition date is still valid.

Valuation semantic: é _k² c1 'or' c2³ = max (é _k² c1³ , é _k² c2³ ) | é _k² c1³ | é _k² c2³

max:: real } real } real - a mathematical operator that returns the greatest of two real numbers.

'xxx' - single quotes turn a function into an infix operator, a Haskell convention.

é _k - a function that takes a contract and outputs the value of the contract, in a specified currency, for each moment in time.