Menu

Design of a Mouldable Programming Language (DMPL)

DMPL is a research project of
the Bergen Language Design
Laboratory, and centres around exploring ideas of flexibility,
adaptability, genericity and robustness (in
short, mouldability) in programming languages. As part of the
project, we are designing and implementing the prototype mouldable
language Magnolia[Bag09], and also putting it to real life testing by developing applications using the language.

The Magnolia Language

Magnolia is designed to support a high level of abstraction, ease of
reasoning (for both humans and computers), separation of concerns,
and robustness.

Concepts are specifications of abstract data types in
Magnolia. A concept consists of one or more abstract types, a set of
operations on those types, and a set of axioms specifying the behaviour
of the operations. Concepts can require (include) other concepts, and
there are a number of operations available for combining and building
concepts. A concept can be thought of as similar to an interface in Java
(or other similar constructs in other languages) – basically
defining the interface of a module – except that concepts also
provides a way to give a (loose) formal specification of the module.

Axioms: Our main uses of axioms are in
testing [BDH09] and
rewriting [BH08], as a ‘light’ use of formal
methods. Axiom-based testing employs axioms as test oracles, which are
fed with (randomly) generated test data. If an axiom evaluates to false
for some data, the implementation does not conform to the
specification. With axiom-based rewriting, axioms are used as rewrite
rules, allowing the compiler to do algebraic simplifications for any data
type. More advanced optimisations can be done by combining rewrite rules
with optimisation strategies.

Implementations: Multiple implementations can be provided for
the same concept, and one implementation will typically rely on several
concepts. For even more flexibility, the same implementation can satisfy
different concepts depending on what concepts it is provided
with. Implementations can be build and manipulated with operations
similar to those available for concepts.

The algorithm-level of the language is similar to a simplified C++,
and is used to provide code for implementations. We use a unified
algebraic signature
style[BH10] for both
imperative and expression-style code. A clear distinction is made
between procedures (which may change their arguments) and functions
(which are ‘pure’, and may not change their arguments). Through the
process of functionalisation, procedures are made available as pure
functions. The pure function form is relates directly to the style
found in specifications and axioms and is also close to the
mathematic expression style underlying numerical programming. The
inverse process of mutification is applied to the code to turn
function calls into procedure calls, which typically require fewer
intermediate temporaries and copying of values.

Error-handling with alerts, which separates the error reporting
mechanism from the error handling mechanism, and allows us to deal
with partiality in a clean way [BDHK06].

Language Design, Implementation and Specification

As part of the project we’re also working on tools and theory for the
specification and implementation of languages. Compiler implementation is
done using Rascal Meta Programming
Language, Java, and generalised parsing techniques.

The syntax description is modular, allowing for language extension, or
even replacing the algorithm-level language while keeping the
concept-level language. Both syntax and semantics will be specified
formally. To support this effort, we are building tools for generating a
compiler frontend from the language
specification [Bag10a].

However, merely specifying a language formally, once the golden
standard of a well designed language, does not guarantee the language
has features that will interact well with each other. Nor does it give
any guidance on how to change those features if they become
insufficient to solve the problems at hand. In order to meet these
challenges, we will also develop a meta-theory for the programming
language features. This theory will have to treat concepts and code as
building blocks [Hav07].

Language Pragmatics

The language implementation is integrated into the Eclipse IDE, with an
editor that supports syntax highlighting and language-specific
operations.

We expect to be able to implement a wide range of editing facilities and
refactorings, since Magnolia is designed to be easy to analyse and reason
about.

Application Development and Maintenance - Validating the Language

The real test for a language, its design and tools, is how well it supports
software development and maintenance. An integral part of the project is
therefore the development of applications in Magnolia in order to gauge
its usefulness and also provide feedback on the language design itself.

Through our earlier work on abstractions for computational science,
the SAGA project,
specifically the work on coordinate-free numerics [HF09],
we have considerable experience in the high performance domain.
This is one of our main application domains for Magnolia.

The high performance domain represents important challenges for a language.
Its main data sets are huge arrays of simulation data, i.e., the data is
not initial or generated in a simple way.
The size of the data also challenges efficiency when handling it,
and processing it benefits from large scale parallelism on challenging hardware architectures.

Though challenging enough, developing applications in one domain
is not sufficient to fully investigate the expressiveness of a language.
We are therefore actively seeking partners in new domains
that are willing to commit know-how and resources in experimenting
with Magnolia.