What Does Aspect-Oriented Programming Mean for Functional Programmers?

Aspect-Oriented Programming (AOP) aims at modularising crosscutting concerns that show up in software. The success of AOP has been almost viral and nearly all areas in Software Engineering and Programming Languages have become "infected" by the AOP bug in one way or another. Interestingly the functional programming community (and, in particular, the pure functional programming community) seems to be resistant to the pandemic. The goal of this paper is to debate the possible causes of the functional programming community's resistance and to raise awareness and interest by showcasing the benefits that could be gained from having a functional AOP language. At the same time, we identify the main challenges and explore the possible design-space

A Case Study in Modular Programming: Using AspectJ and OCaml in an Undergraduate Compiler Project

We report our experience in using two different languages to build the same software project. Specifically, we have converted an entire undergraduate compiler course from using AspectJ, an aspect-oriented language, to using OCaml, a functional language. The course has evolved over a period of eight years with, on average, 60 students completing it every year. In this article, we analyze our usage of the two programming languages and we compare and contrast the two software projects on a number of parameters, including how they enable students to write and test individual compiler phases in a modular way.

An Exceptional Actor System (Functional Pearl)

The Glasgow Haskell Compiler is known for its feature-laden runtime system (RTS), which includes lightweight threads, asynchronous exceptions, and a slew of other features. Their combination is powerful enough that a programmer may complete the same task in many different ways -- some more advisable than others. We present a user-accessible actor framework hidden in plain sight within the RTS and demonstrate it on a classic example from the distributed systems literature. We then extend both the framework and example to the realm of dynamic types. Finally, we raise questions about how RTS features intersect and possibly subsume one another, and suggest that GHC can guide good practice by constraining the use of some features.Comment: To appear at Haskell Symposium 202

MetaBETA: Model and Implementation

Object-oriented programming languages are excellent for expressing abstractions in many application domains. The object-oriented programming methodology allows real-world concepts to modelled in an easy and direct fashion and it supports refinement of concepts. However, many object-oriented languages and their implementations fall short in two areas: dynamic extensibility and reflection.Dynamic extensibility is the ability to incorporate new classes into an application at runtime. Reflection makes it possible for a language to extend its own domain, e.g., to build type-orthogonal functionality. MetaBETA is an extension of the BETA language that supports dynamic extensibility and reflection. MetaBETA has a metalevel interface that provides access to the state of a running application and to the default implementation of language primities.This report presents the model behind MetaBETA. In particular, we discuss the execution model of a MetaBETA program and how type- orthogonal abstractions can be built. This includes precentation of dynamic slots, a mechanism that makes is possible ectend objects at runtime. The other main area covered in this report is the implementation of MetaBETA. The central component of the architecture is a runtime system, which is viewed as a virtual machine whose baselevel interface implements the functionality needed by the programming language

Loan pricing model : design and implementation

Thesis (M. Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 1996.Includes bibliographical references (leaf 40).by Ashish Sharma.M.Eng

An Investigation Into the Generality of a Graphical Representation of Program Code for Source to Source Translation

This thesis addresses the problem of defining a source-to-source translation system for reusable software components. It describes the development of an interoperable language for writing software components, and presents a system to translate components written in the interoperable language to a set of compatible target languages. The common features in a set of popular programming languages are analyzed to inform the design of the interoperable language. An evaluation is performed by using the source-to-source translator to convert two well-known open source Java libraries to C++ and Python, and the accuracy and performance of the resulting translations are assessed

A Reflection on Types

The ability to perform type tests at runtime blurs the line between statically-typed and dynamically-checked languages. Recent developments in Haskell’s type system allow even programs that use reflection to themselves be statically typed, using a type-indexed runtime representation of types called \{}\textit{TypeRep}. As a result we can build dynamic types as an ordinary, statically-typed library, on top of \{}\textit{TypeRep} in an open-world context