Even when programming in a statically typed language we every now and then encounter statically untypable values; such values result from interpreting values or from communicating with the outside world. To cope with this problem most languages include some form of dynamic types. It may be that the core language has been explicitly extended with such a type, or that one is allowed to live dangerously by using functions like unsafeCoerce. We show how, by a careful use of existentially and universally quantified types, one may achieve the same effect, without extending the language with new or unsafe features. The techniques explained are universally applicable, provided the core language is expressive enough; this is the case for the common implementations of Haskell. The techniques are used in the description of a type checking compiler that, starting from an expression term, constructs a typed function representing the semantics of that expression. In this function the overhead associated with the type checking is only once being paid for; in this sense we have thus achieved static type checking.

Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts. We introduce a combinator library that allows us to describe such contracts precisely, and a compositional denotational semantics that says what such contracts are worth. We sketch an implementation of our combinator library in Haskell. Interestingly, lazy evaluation plays a crucial role. 1 Introduction Consider the following nancial contract, C: the right to choose on 30 June 2000 between D1 Both of: D11 Receive $100 on 29 Jan 2001. D12 Pay $105 on 1 Feb 2002. D2 An option exercisable on 15 Dec 2000 to choose one of: D21 Both of: D211 Receive $100 on 29 Jan 2001. D212 Pay $106 on 1 Feb 2002. D22 Both of: D221 Receive $100 on 29 Jan 2001. D222 Pay $112 on 1 Feb 2003. The details of this contra...

valuation semantics. First, we will show how to translate an arbitrary contract, written in our language, into a value process, together with a handful of operations over these processes. These processes correspond directly to the mathematical and stochastic machinery used by nancial experts.

This paper uses the Fran system for functional reactive animation to give a simulation of a lift -- or elevator -- with many floors. The paper first introduces a two-floor version, and then indicates in detail how this is extended to give a simulation with an arbitrary number of floors and featuring more realistic animated graphics.

Abstract not found

Abstract. We propose multi-language synchronization, a novel approach to the problem of migrating code from a legacy language (such as C) to a new language. We maintain two parallel versions of every source file, one in the legacy language, and one in the new language. Both of these files are fully editable, and the two files are kept automatically in sync so that they have the same semantic meaning and, where possible, have the same comments and layout. We propose non-deterministic language translation as a means to implement multi-language synchronization. If a file is modified in language A, we produce a new version in language B by translating the file into a non-deterministic description of many ways that it could be encoded in language B and then choosing the version that is closest to the old file in language B. To demonstrate the feasibility of this approach, we have implemented a translator that can synchronize files written in a straw-man language, Jekyll, with files written in C. Jekyll is a high level functional programming language that has many of the features found in modern programming languages. 1

Formal framework for reasoning about programs are important not only for automated tools but also for programmers. Type systems have proven an enormously popular framework for validating static analyses of programs, as well as for documenting their interfaces for programmers. However, most type systems used in practice today fail to capture many essential aspect of p behavior dependencie of programs The considerabl c i pas twenty years int developing that captu e information I pape examin compa contrast connec mbe o highly influentia p ototy ica system capturing dependencies Specifically w classi e typ system a onceive fo l canonical example o pendenc system system information-flow di moda systems c (co)monadi e fec dependenc discipline linear system p e- easonin abou state esou Finally als esen calculus provide insight possibili fo a unified account for all of these systems.

Currently, much of the software that we would like to run fast on multi-core processors is written in C — a language in which expressing concurrency is difficult and error prone. Unfortunately, moving such programs to a new language is very difficult, since the programmers only know C, the tools only know C, and developers are unkeen to trust their projects to a language that might not be supported in a few years time. Our solution to this problem is Jekyll — a high level language that is losslessly inter-translatable with readable, editable C. This allows Jekyll to take advantage of C programmers and C tools, since they can use the C version of a Jekyll file, and means that if Jekyll ever ceases to be maintained, developers still have a usable C code-base. 1.

A domain-specific embedded language (DSEL) is a domain-specific programming language with no concrete syntax of its own. Defined as a set of combinators encapsulated in a module, it borrows the syntax and tools (such as type-checkers and compilers) of its host language; hence it is economical to design, introduce, and maintain. Unfortunately, this economy is counterbalanced by a lack of room for growth. DSELs cannot match sophisticated domain-specific languages that offer tools for domainspecific error-checking and optimisation. These tools are usually based on syntactic analyses, so they do not work on DSELs. Abstract interpretation is a technique ideally suited to the analysis of DSELs, due to its semantic, rather than syntactic, approach. It is based upon the observation that analysing a program is equivalent to evaluating it over an abstract semantic domain. The mathematical properties of the abstract domain are such that evaluation reduces to solving a mutually recursive set of equations. This thesis shows how abstract interpretation can be applied to a DSEL by replacing it with an abstract implementation