[UMN logo]

CSCI 8980: Advanced Topics in Programming Languages
Fall 2006, Class Presentations

The students in this course will be giving a series of presentations on topics related to programming languages that they have been studying as part of individual class projects. The titles of their presentations and dates are listed below. Clicking on the link will lead you to an abstract for the talk and also some papers that might be read beforehand to get the most out of the talk.

All the presentations will take place in Room 156, Amundson Hall from 9:45 till 11:00 a.m. If the topic of any of the lectures appears interesting, the class invites you to come and listen to it.

Compilation of Strong Reduction
Andrew Gacek


Traditional abstract machines for functional languages implement a weak reduction strategy where evaluation stops upon reaching a function abstraction. An alternative strategy, known as strong reduction, is to continue performing reductions even underneath function abstractions. In this talk we look at extensions to existing abstract machines to allow for strong reduction. First in a strict evaluation setting based on the Categorical Abstract Machine and second in a lazy evaluation setting based on the Krivine Abstract Machine.


  1. B. Gregoire and X. Leroy. A compiled implementation of strong reduction. In Proceedings of the Seventh ACM SIGPLAN International Conference on Functional Programming, pages 235-246, Pittsburgh, October 2002. ACM Press.
  2. P. Cregut. An abstract machine for lambda-terms normalization. Proceedings of the 1990 ACM conference on LISP and functional programming, pages 333-340, Nice, France, 1990. ACM Press.

Incremental Garbage Collection and Purely Functional Languages
August Schwerdfeger


It is common practice in the world of functional programming (including in interpreters of ML and Haskell) to use generational garbage collection. While this model has its advantages, the garbage collectors used still work in the "stop-the-world" manner, which sometimes mandates noticeable pause times.

A solution is to use incremental garbage collection, which performs its function in time-bounded steps so as to avoid those pause times. Of course, this raises the issue of how to keep the garbage collector hidden from the "mutator" (user program).

Methods used for this purpose are the "read barrier" and the "write barrier," which keep an eye on each of those respective actions from the mutator. Of these, the write-barrier algorithm is the most useful for purely-functional languages, which perform no writes at all.


  1. Nettles, S. and O'Toole, J. 1993. Real-time replication garbage collection. In Proceedings of the ACM SIGPLAN 1993 Conference on Programming Language Design and Implementation (Albuquerque, New Mexico, United States, June 21 - 25, 1993). R. Cartwright, Ed. PLDI '93. ACM Press, New York, NY, 217-226.
  2. Baker, H. G. 1992. The treadmill: real-time garbage collection without motion sickness. SIGPLAN Not. 27, 3 (Mar. 1992), 66-70.

Deciding Combinations of Theories
Lijesh Krishnan


In this presentation, we look at the question of deciding equalities in theories which are themselves combinations of decidable theories.

A theory has associated with it of a set of function symbols and equalities. For example, a theory of list operator terms has the equalities:

        car (cons (x, y)) = x
        cdr (cons (x, y)) = y
        cons (car (x), cdr (y)) = x
Given these equalities, and the following formula,
        cons (car (x), cdr (car (y))) = cdr (cons (y, x))
we would like to know what assignments to the free variables make the equality true (and if there are no free variables, if the formula is true or false). The formula above is true under the assignment
        y = cons (cons (a, cdr (x)), d)
where a and d are new free variables.

We first look at work by Nelson and Oppen which uses the concept of graph congruence closures to derive a fast algorithm for deciding equality of terms in certain theories (such as the list operator theory above). We then look at work by Shostak that extends this algorithm to decide combinations of theories. For example, given a theory consisting of the combination of lists and linear arithmetic, Shostak's algorithm takes the formula

        5 + car (x + 1) = cdr (x + 2) + 3
(which has both list operators and linear arithmetic operators) and returns the assignment
        x = cons (cdr (x + 2) - 2, d) - 1
where d is a new free variable. Shostak's algorithm was revised and corrected in work by Ruess and Shankar.

In the references below, the most important one to look at is the paper by Shostak. If you get through this, then the one to look at next is the paper by Nelson and Oppen.


  1. Greg Nelson and Derek C. Oppen. Fast decision procedures based on congruence closure. J. ACM, 27(2):356-364, 1980.
  2. Robert E. Shostak. Deciding combinations of theories. J. ACM, 31 (1):1-12, 1984.
  3. Harold Ruess and Natarajan Shankar. Deconstructing Shostak. In LICS '01: Proceedings of the 16th Annual IEEE Symposium on Logic in Computer Science, IEEE Computer Society.

Programming Language Interoperability
Jeremy Adamich


There are many different programming languages available and some are better suited to certain problem domains [1, 2]. This raises the question of how to choose a language to solve a particular problem that may cross multiple domains. In this situation, it may be advantageous to use multiple languages in one project. This raises issues regarding incompatible data representation as well as incompatible function calling conventions and also memory management. The focus of this presentation will be on data representation issues.

The representation of primitive data types differs in each language. Also, there are some primitive data types like pointers in C, or native data types like lists in ML that may have no representation in the other language. Further more, the layout of aggregate data types such as tuples in ML and unions in C may require explicit mapping directives from the programmer in order for them to be used between languages.

One approach to interoperability is called Representation Level Interoperability (RLI). RLI hides such differences as byte orders, floating-point precisions, or array accessing mechanisms [3]. An example of RLI is the SML of NJ ~ C Foreign Function Interface library. This library provides a mapping between primitive data types as well as aggregate data types, however, the programmer must provide some details about data types and values that are passed from C to ML [4].

Another approach to interoperability is called Specification Level Interoperability (SLI). SLI extends RLI by hiding representation differences for abstract types as well as simple types [3]. An example of SLI is SML.NET. SML.NET is a compiler for Standard ML that targets the Mircrosoft Common Language Infrastructure, producing Microsoft Common Intermediate Language as its object code [5]. The Common Intermediate Language and the Common Language Runtime have been designed from the ground up to support high level programming language interoperability [6] in a transparent way. In this development environment, a programmer can make use of a data type or functions written in one language directly in another language. The translation or mapping of data representations is handled by the CIL [7].

As an example, say we want to write a library in ML that contains a binary tree datatype and we want to use this datatype in a program which we will write in C or some other imperative language. Two solutions for this trivial example will be presented, one using SML/NJ-C FFI and the other using SML.NET, in order to show how these data representation issues can be addressed and interoperability can be achieved.

Of the references below, [4] and [5] are the ones that you should read to get the most out of the presentation.


  1. C. Wileden, A. Kaplan, Software Interoperability: Principles and Practices, Proceedings of the 1999 International Conference on Software Engineering, Pages 675 - 676, Los Angeles CA, 1999
  2. W. G. Griswold, R. Wolski, S. B. Baden, S. J. Fink, S. R. Kohn, Programming Language Requirements for the Next Millenium, ACM Computing Surveys, Volume 28 Number 4, ACM, 1996.
  3. J. C. Wileden, A. L. Wolf, W. R. Rosenblatt, P.L. Tarr, Specification Level Interoperability, Communications of the ACM, Volume 34, Issue 5, Pages 72 - 87, 1990
  4. L. Huelsbergen, A Portable C Interface for Standard ML of New Jersey. AT&T Bell Laboratories, January, 1996.
  5. N. Benton, A. Kennedy, C. V. Russo, Adventures in Interoperability: The SML.NET Experience. PPDP 04, ACM, August 24-26, 2004, Verona, Italy.
  6. J. Hamilton, Language Integration in the Common Language Runtime. SIGPLAN Notices Volume 38, Issue 2, Pages 19 - 28, 2003.
  7. D. Syme, ILX: Extending the .NET Common IL for Functional Language Interoperability. In BABEL'01: First International Workshop on Multi-Language Infrastructure and Interoperability, September 2001.

Adoption of Programming Languages
Shilad Sen


In his manifesto on the power of functional languages, John Hughes writes
"... two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity.... Since modularity is the key to successful programming, functional languages are vitally important to the real world." [1]
Twenty years have passed since Hughes proclaimed the advantages of functional programming. Functional languages remain, at best, a niche segment of the commercial programming language market. A recent survey found that the most popular functional language garnered only one tenth of a percent of the commercial market share [2].

In this talk, I will discuss the factors that lead programmers to adopt programming languages. I will summarize existing research and commentary from HCI researchers programming language educators and researchers, and industry pundits. I will conclude with a roundtable discussion on the future of programming languages.


  1. John Hughes, Why functional programming matters. Technical Report 16, Programming Methodology Group, University of Goteborg, November 1984.
  2. OCaml scored 0.102% at the "TIOBE Community Programming Index in November 2006"

Type Checking of Objects in O'Caml
Zachary Snow

Objective Caml provides a powerful, type safe object oriented system for ML. Type inference allows a very eloquent and brief syntax for invoking methods of objects, and for constructing polymorphic functions that operate on objects. As a motivation for the study of such a system, my presentation will first provide a brief introduction to O'Caml's object system, and a description of the power afforded by such a system. As will be explained, the object system provided by O'Caml is, in general, one that treats objects as polymorphic records. The primary focus of the presentation will be on the description of a method of type-checking the system based on the use of row variables to represent records containing possibly unknown fields.

Participants will get the most out of this presentation if they have had some small exposure to the object system in O'Caml, and if they have a basic understanding of unification in a function language like ML.


  1. Hickey, Jason. Introduction to Ocaml. 2006.
  2. Remy, D. and J. Vouillon. Objective ML: An effective object-oriented extension to ML, TAPOS, 4, 1998, pp. 27--50.

Last modified: November 16, 2006 by gopalan@cs.umn.edu