Concurrency control is mostly based on locks and is therefore notoriously difficult to use. Even though some programming languages provide high-level constructs, these add complexity and potentially hard-to-detect bugs to the application. Transactional memory is an attractive mechanism that does not have the drawbacks of locks, however the underlying implementation is often difficult to integrate into an existing language. In this paper we show how we have introduced transactional semantics into Smalltalk by using the reflective facilities of the language. Our approach is based on method annotations, incremental parse tree transformations and an optimistic commit protocol. The implementation does not depend on modifications to the virtual machine and therefore can be changed at the language level. We report on a practical case study, benchmarks and further and on-going work.

Concurrent programming is now becoming more important than ever. But for concurrent programs to work deterministically, sections of the code must be synchronised. The most common method of synchronising code is to protect the code with locks. However, code which uses locks is difficult to write and even more difficult to debug. Locking also makes it difficult to compose large programs from smaller ones. A relatively new method of synchronisation, known as Software Transactional Memory, is promising to be a much easier method of synchronisation. This thesis describes the design and implementation of a Software Transactional

The benefits of modularization are well known. However, modules are not standard in Scheme. This paper accompanies an invited talk at the Scheme Workshop 2002 on the current state of modules for Scheme. Implementation is not addressed, only linguistic features are covered.

Programs in high-level, garbage-collected programming languages often need to access libraries that are written in other programming languages. A foreign-function interface provides a high-level language with access to low-level programming languages and negotiates between the inside and the outside world by taking care of the low-level details. In this paper, I provide an overview of what different kinds of foreign-function interfaces are in use in today’s implementations of functional programming languages to help decide on the design of a new foreign-function interface for Scheme 48. I have revised several mechanisms and design ideas and compared them on usability, portability, memory consumption and thread safety. I discuss the garbage-collection related parts of foreign-function interfaces using Scheme as the high-level functional language and C as the external language. 1.