Functional programming may be beautiful, but to write real applications we must grapple with awkward real-world issues: input/output, robustness, concurrency, and interfacing to programs written in other languages. These lecture notes give an overview of the techniques that have been developed by the Haskell community to address these problems. I introduce various proposed extensions to Haskell along the way, and I offer an operational semantics that explains what these extensions mean. This tutorial was given at the Marktoberdorf Summer School 2000. It will appears in the book “Engineering theories of software construction, Marktoberdorf Summer School 2000”, ed CAR Hoare, M Broy, and R Steinbrueggen, NATO ASI Series, IOS Press, 2001, pp47-96. This version has a few errors corrected compared with the published version. Change summary: Apr 2005: some examples added to Section 5.2.2, to clarifyevaluate. March 2002: substantial revision 1

Electronic systems are becoming more complex. Using subproblem-specific languages simplifies their design, but presents the problem of connecting the parts. I propose a system description scheme for reactive systems (systems that maintain a dialog with their environment) that supports such heterogeneity. I expect to contribute the system description scheme, a mathematical framework for it, a set of efficient algorithms for simulating these systems, and a practical implementation of the scheme. My prototype compiler suggests this scheme can be made practical, and the mathematical framework is nearly complete. I expect this work to make designing complex, heterogeneous reactive systems fast and simple. 1 Introduction Electronic systems are growing more complex. Describing these with a diverse set of languages, each suited to a particular subtask, can greatly simplify designing these systems, but the problem of connecting the subtasks arises. For example, a convenient descriptionof the d...

In this paper we show that it is possible to identify the author of a piece of software by looking at stylistic characteristics of C source code. We also show that there exist a set of characteristics within a program that are helpful in the identi cation of a programmer, and whose computation can be automated with a reasonable cost. There are four areas that bene t directly from the ndings we present herein: the legal community can count on empirical evidence to support authorship claims, the academic community can count on evidence that supports authorship claims of students, industry can count on identifying the author of previously un-identi able software modules, and real time intrusion detection systems can be enhanced to include information regarding the authorship of all locally compiled programs. We show that it is possible to identify the author of a piece of software by collecting and identifying eighty-eight programs for twenty nine students, sta and faculty members at Purdue University.

Abstract. In the two decades hand-held calculators have been readily available there has been ample time to develop a usable design and to educate the consumer public into choosing quality devices. This article reviews a representative calculator that is ‘state of the art’ and shows it has an execrable design. The design is shown to be confusing and essentially non-mathematical. Substantial evidence is presented that illustrates the inadequate documentation, bad implementation, feature interaction, and feature incoherence. These problems are shown to be typical of calculators generally. Despite the domain (arithmetic) being welldefined, the design problems are profound, widespread, confusing—and needless. Worrying questions are begged: about design quality control, about consumer behaviour, and about the role of education—both at school level (training children to acquiesce to bad design) and at university level (training professionals to design unusable products). The article concludes with recommendations. “The problem of efficient and uniform notations is perhaps the most serious one facing the mathematical public. ” Florian Cajori [5]. “[...] contrivances adapted to peculiar purposes [...] and what is worse than all, a profusion of notations (when we regard the whole science) which threaten, if not duly corrected, to multiply our difficulties instead of promoting our progress. ” Charles Babbage, quoted in [5]. 1

Object-oriented computing is influencing many areas of computer science including software engineering, user interfaces, operating systems, programming languages and database systems. The appeal of object-orientation is attributed to its higher levels of abstraction for modeling real world concepts, its support for incremental development and its potential for interoperability. Despite many advances, object-oriented computing is still in its infancy and a universally acceptable definition of an object-oriented data model is virtually nonexistent, although some standardization efforts are underway. This report presents the TIGUKAT 1 object model definition that is the result of an investigation of object-oriented modeling features which are common among earlier proposals, along with some distinctive qualities that extend the power and expressibility of this model beyond others. The literature recognizes two perspectives of an object model: the structural view and the behavioral view. ...

Denotational semantics is now used widely for the formal definition of programming languages but there is a lack of appropriate tools to support language development. General purpose language implementation systems are oriented to syntax with poor support for semantics. Specialised denotational semantics based systems correspond closely to the formalism but are rendered inflexible for language experimentation by their monolithic multiple stages Exploratory language development with formal definitions is better served by a unitary notation, encompassing syntax and semantics, which is close to but simpler than denotational semantics. Interactive implementation of the notation then facilitates language investigation through the direct execution of a formal definition as an interpreter for the defined language. This thesis presents Navel, a run-time typed, applicative order, pure functional programming language with integrated context free grammar rules. Navel has been used to develop prot...

Abstract: Rosetta is a systems level design language that allows algebraic specification of systems through facets. The usual approach to formally describe a specification is to define an algebra that satisfies the specification. Although it is possible to formally describe Rosetta facets with the use of algebras, we choose to use the dual of algebra, i.e. coalgebra, to do so. Coalgebras are particularly suited for describing statebased systems. This makes formally defining state-based Rosetta quite straightforward. For non-state-based Rosetta, the formalization is not as direct, but can still be done with coalgebras by focusing on the behaviors of systems specified. We use denotational semantics to map Rosetta syntactic constructs into a language understood by the coalgebras.

One of the major overheads in implementing functional languages is the storage management overhead due to dynamic allocation and automatic reclamation of indefinite-extent storage. This dissertation investigates the problems of statically inferring lifetime information about dynamically-allocated objects in higher-order polymorphic functional languages, both strict and non-strict, and of applying that information to reduce the storage management overhead. We have developed a set of compile-time semantic analyses for a higher-order, monomorphic, strict functional language based on denotational semantics and abstract interpretation. They are 1) escape analysis, which provides information about the relative lifetimes of objects such as arguments and local objects defin...

syntax of Gull Figure 2. A Gull Program countdown and ML-Yacc. These programs are similar to the well-known Unix tools, enabling a system builder to handle complex languages. Since the purpose here is to study semantics, the central definition of syntax is the abstract syntax, and an associated concrete syntax is provided in such a way as to make the scanning and parsing simple. Although ML-Lex and ML-Yacc are used for the ML version, the Prolog version relies on a hand-built scanner and parser.

this article provides a tutorial introduction to these techniques. While little here will be new to the language theorist, some of what is here may be of use to the markup technologist.