System Design can be Language Design
by Jørgen Steensgaard-Madsen
A set of software components can provide the meaning of a specialised
programming language, with one component giving the meaning of one form
of statement. This view on what constitutes a component stresses compositionality
as the most important factor and allows late, dynamic composition of components.
Ideally one might express component definitions and compositions in the
same language. The actual approach is to allow definitions written in a
commonly used language and compositions to be expressed in a model language.
The ULC-system(Uniform Language of Composition) is a tool being developed
by the author at the Technical University of Denmark to support the view
expressed above, and it is ready for field tests. Among the many academical
tests carried out, support for multiprogramming primitives deserves mention.
The project is based on the hypothesis that system design can be language
design. It is normative because it supports a particular view on the component
concept and a related view on language design. Some components can be considered
classes as known from object-oriented programming languages. But a component
may be even more general as for instance a higher-order class of objects
having classes as members.
The relevance of the hypothesis is, of course, only a conviction that
eventually should be justified by experience. But the need to compose separately
defined components corresponds to a need for a language to express compositions,
and this is taken as a strong evidence for the relevance of the focus on
languages.
In practice a component will often represent pragmatic knowledge about
the use of primitives from various existing libraries. The relation between
components and library primitives can be compared to the relation between
structured programming languages and assembler languages. A typical exercise
is to set up a structure of processes interconnected by pipes as outlined
in the figure.
This cannot be done in a typical Unix-shell, and it requires a good
deal of pragmatic expertise to express it in C. The program text in the
sidebar shows a readable expression for it in an appropriate ULC-language.
In simple terms a component is a subroutine (of higher-order in some
model language though.) Dynamic composition of components can be realised
as an interpreter for combined calls of such routines. A composition language
can consequently be described by something similar to prototypes
as in a C header file for a set of subroutines.
The ULC-system can generate an interpreter from descriptions in a header
file. The interpreters will be called ULC-interpreters and their input,
ULC-languages. The ULC-system has characteristics similar to conventional
compiler or interpreter generators, with the header file corresponding
to the syntactic descriptions needed by such generators. Conventional generators
state meanings in terms of syntax trees. The ULC-system requires meanings
given as components, and these are independent of the tool's internals
and of syntax trees in particular.
A generalised syntax for subroutine calls, that look more like structured
statements, is implemented at the user interface. This interface is common
to the ULC-interpreters. A particular command is translated into a syntax
tree with the meaningful tokens from the call encoded lexically. The ULC-system
can then directly interpret the syntax tree or translate it into the component
definition language.
Addition of new statements and operators to an existing ULC-language
is easy. Components are written separately in an ordinary programming language,
so ULC-languages are expected to be developed incrementally. Portability
is presently obtained by depending on the source language accepted by GNU
C (with extensions!) as the implementation language.
Dynamic composition of components has particular interest during system
development, even for systems that do not require this themselves. Translating
commands into GNU C, whereby one can obtain a program that is independent
of the ULC-system, should make the ULC-system useful for program development
in general.
A type system is used for the description of subroutine prototypes and
commands are checked accordingly. But no type appears in a command, since
the descriptions are detailed enough to let the system infer actual types
where needed.
Several aims are pursued with the project: it should lead to a tool
that is practically useful; the basic hypothesis should be tested; the
formal meaning of the tool itself has to be determined; several ideas about
language design are examined; and the notion of components should be exercised
in new areas.
The ULC-system is ready for tests with applications that are either
suitable for students' projects or require industrial cooperation.
A particular area of interest for further research will be generation
of embedded system software, especially generation of kernels for arbitration
of process.
A particular relation to logic and formal semantics is promising with
respect to achieve formal specifications of components and hence enable
formal validation of command properties.
Further information about the contents and current results is available
via the author's home page at: http://www.it.dtu.dk/~jsm
Please contact:
Jørgen Steensgaard-Madsen - Technical University of Denmark
Tel: +45 4525 3732
E-mail: jsm@it.dtu.dk
