University of Ulm, Faculty of Informatics, Department of Computer Structures
TIMOR - Types,
Implementations and More
The Liberation from Java's Restrictions
Prof. Dr. Dr. J. Leslie Keedy
Dr. Christian Heinlein
Dr. Gisela Menger
The Timor Programming Language
Timor is a new programming language currently being designed at the
University of Ulm in Germany. The project began in late 1999 at about
the same time as an Australian led UNO peacekeeping force was
authorised to rescue East Timor from the repression under which it was
suffering at the hands of Indonesian forces - hence the caption above.
The Background of the Project
The Timor project is the successor to a number of programming language projects undertaken
earlier in the Department of Computer Structures at the University of
Ulm. These concentrated on individual aspects of programming language
design and each culminated in the development of a programming language
which was based on Java and was designed with the intention of
improving individual aspects of that language. These languages were as
follows:
- Genja: enhanced
Java by adding unconstrained genericity. Genja was designed and
implemented by Dr. Mark Evered, who has sinced moved to the University
of New England, in Armidale, N.S.W., Australia.
- Collja: built on Genja,
adding a behaviourally conform collection library based on combinations
of the following orthogonal principles:
- ordering of elements (unordered, user-ordered, sorted)
- duplication of elements (duplicates permitted, ignored,
treated as error)
and providing a uniform
built in syntax for the resulting types in the language. Collja was
designed and implemented by Dr. Gisela Menger, as part of her Ph.D.
thesis.
- Tau: enhanced Java by
separating types (interfaces) from their potentially multiple
implementations (classes, which are not types). Tau was designed and
implemented as part of the Ph.D. thesis of Dr. Axel Schmolitzky, who
has sinced moved to the University of Hamburg in Germany.
The concepts developed in these three projects all play a significant
role in the design of Timor.
Dr. Christian Heinlein completed a Ph.D. in another department of
the Faculty of Computer Science at Ulm in the area of synchronisation,
with a concept known as interaction expressions. He joined the
Timor project at the beginning of 2001. In addition to his work on
Timor, Dr. Heinlein develops
Advanced Procedural
Programming Language
Elements (APPLE), such as truly extensible types,
entity-relationship-like data structures, guarded procedures, etc. The
work on these topics is also proving to be a fruitful source of
inspiration for the design of Timor.
Publications on Timor
Timor Publications:
[1] J. L. Keedy, G. Menger, and C. Heinlein,
"Support for Subtyping and Code Re-use in Timor," 40th International
Conference on Technology of Object-Oriented Languages and Systems
(TOOLS Pacific 2002), Sydney, Australia, 2002, Conferences in Research
and Practice in Information Technology, vol. 10, pp. 35-43. (pdf file)
[2] J. L. Keedy, G. Menger, and C. Heinlein,
"Inheriting from a Common Abstract Ancestor in Timor," Journal of
Object Technology, vol. 1, no. 1, pp. 81-106, 2002.
See http://www.jot.fm/issues/issue_2002_05/article2
[3] J. L. Keedy, G. Menger, C. Heinlein, and F.
Henskens, "Qualifying Types Illustrated by Synchronisation Examples,"
Net.ObjectDays, Erfurt, Germany, 2002, pp. 334-348. (see [4]).
[4] J. L. Keedy, G. Menger, C. Heinlein, and F.
Henskens, "Qualifying Types Illustrated by Synchronisation Examples,"
in Objects, Components, Architectures, Services and Applications for a
Networked World, International Conference NetObjectDays, NODe 2002,
Erfurt, Germany, vol. LNCS 2591, M. Aksit, M. Mezini, and R. Unland,
Eds.: Springer, 2003, pp. 330-344.
(Reprint of [3]).
See http://link.springer.de/link/service/series/0558/papers/2591/25910330.pdf
[5] J. L. Keedy, K. Espenlaub, G. Menger, and C.
Heinlein, "Qualifying Types with Bracket Methods in Timor," Journal of
Object Technology (to appear Jan/Feb 2004)
The Aims of Timor
A primary motivation for the design of Timor is the idea that the
development of large software systems should make extensive use of
pre-existing, modular components. Like Doug McIlroy,
who proposed this idea more than thirty years ago, we consider that
such components should not be large, but should rather be small,
general purpose components (such as a type Date) which can be re-used
in many systems, just
as nuts and bolts can be used as components in many artifacts and
engineering
systems.
A language which supports such a concept should be capable of
allowing software components to be specified and defined independently
of
particular implementations, thus providing programmers with the freedom
to develop multiple interchangeable implementations for the same
component
definition. This approach is best realised by designing components
according to the information hiding principle, which was formulated by
David Parnas - also more than thirty
years ago.
Unfortunately languages designed to support the object oriented
programming (OOP) paradigm do not provide rigorous support for the
information hiding principle. At least the following shortcomings
exist:
- The OOP class construct unites a type and an implementation into
a single construct. Although it is possible to use inheritance
(abstract types, Java interfaces) as a mechanism to simulate a type
definition and multiple implementations, such techniques have a number
of problems, not least of which is that a concrete class which is then
used as an implementation unit is itself a new type.
- Widely used OOP languages allow public fields to be defined in
classes. Although this can be convenient for programmers it blatantly
contravenes the information hiding principle, and greatly impedes the
idea of having multiple interchangeable implementations for a type.
- There are several well-known problems (cf. Bruce et al.) associated with binary methods
(e.g. methods which compare two objects of the same type). The idea
that such methods may be required to handle two or more objects of the
same type with different implementations complicates this issue.
Inheritance, the other showpiece of OOP languages, can also create
problems for the development of modular software components
which are intended to be used as building blocks which can be mixed and
matched together to build large software systems. Here are some
examples:
- As is well known, subtyping (the specialisation of a type for
use as a further type, e.g. a person specialised as a student) and
subclassing (the inheritance of code from a superclass, e.g.
a queue, for use in a subclass, e.g. a double-ended queue), which are
united into a single concept in the classical OOP paradigm, are often
incompatible, especially if behavioural conformity (cf. Liskov and Wing) is desirable at the type level.
- The idea of a subclass is not modular, in that the
"extension" is not a separate modular unit available for re-use in
other types, even in cases where the extension has its own separable
state and its own methods.
- This lack of modularity becomes particularly evident in the case
of multiple code inheritance from subclasses which have
a common concrete ancestor (the classical "diamond inheritance"
problem).
- Other cases of multiple inheritance can also be problematic,
especially when the supertypes have members which have clashing names
and/or a common purpose. Should such members be treated as separate
members in the derived class, or should they be combined?
Leaving aside the inadequacies of the class construct and
inheritance, the OOP paradigm is also unable to provide an adequate
framework for other modularity requirements, as the proponents of
Aspect
Oriented Programming (AOP) have made clear in recent years. The
difficulty
is in allowing separate "aspects" of a program (e.g. synchronisation,
monitoring) to be programmed as separate modules which can later easily
be combined into the required program. Even AOP languages designed to
overcome such difficulties by extending existing OOP languages (e.g.
AspectJ and AspectC++) are unable to achieve this aim in a fully
flexible,
modular way (without requiring the programmer to follow strict
conventions)
because of the difficulties in the OOP paradigm, as the following
example
shows.
- The pattern for implementing reader-writer synchronisation is
simple and well-known, yet it is not possible, either in existing OOP
or AOP languages to write a module which contains the required code and
combine this module with any other arbitrary module which has
not been especially written with conventions designed to make this
possible.
The above difficulties are all addressed in Timor, which therefore
differs from other languages not so much in the syntax of its normal
code statements (which have been designed as far as possible to
resemble Java and C++) but in its basic structure. In addition Timor
also addresses the following aims:
- The provision of a high degree of protection and security,
especially but not only in the area of distributed object systems.
- A simple but powerful and effective form of multithreading.
M. D. McIlroy, "Mass Produced Software
Components," NATO Conference on Software Engineering, NATO Science
Committee,
Garmisch, Germany, 1968, Petrocelli-Charter, pp. 88-98.
D. L. Parnas, "Information Distribution
Aspects of Design Methodology," 5th World Computer Congress, IFIP-71,
1971, IFIP, pp. 339-344.
D. L. Parnas, "On the Criteria To Be Used in Decomposing Systems
into Modules," Communications of the ACM, vol. 15, no. 12, pp.
1053-1058, 1972.
D. L. Parnas, "A Technique for Module Specification with Examples,"
Comm. ACM15, 5, pp. 330-336, 1972.
K. B. Bruce, L. Cardelli, G. Castagna, T. H.
O. Group, G. T. Leavens, and B. Pierce, "On Binary Methods," Theory and
Practice of Object Systems, vol. 1, no. 3, pp. 221-242, 1995.
B. Liskov and J. M. Wing, "A Behavioral Notion
of Subtyping," ACM Transactions on Programming Languages and Systems,
vol. 16, no. 6, pp. 1811-1841, 1994.
The Current State of Timor
Timor is an ambitious project which will lead to a programming
language which is in several respects structurally different to all
previous programming languages. Despite our efforts to handle the
various concepts involved orthogonally, these inevitably affect
each other, so that a decision made in one area can have unexpected
effects in a different area. Consequently we are adopting a cautious
approach with respect to
formal publication (except with respect to minor syntactic details)
until
we are reasonably sure that a paper contains decision which can be
regarded
as relatively firm.
The design of Timor is not yet complete, and there is as yet no
implementation.
Some Timor Themes
- The Influence of Natural Language (not
yet available)
- Information Hiding (not yet available)
- The Basic Model (not yet available)
- Inheritance and Code Re-use (not yet
available)
- Multiple Inheritance (not
yet available)
- Collection Library and Integrated Syntax
(not yet available)
- Qualifying Types and Bracket Methods
(not yet available)
- Protection and Security and the relation to SPEEDOS (not yet available)
- Multithreading (not yet available)
Leslie Keedy, 10 May
2003:
keedy@informatik.uni-ulm.de