The Liberation from Java's RestrictionsProf. 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: [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, vol. 3, no. 1, 2004, pp.101-121. See http://www.jot.fm/issues/issue_2004_01/article1
[6] Keedy, J.L., Menger, G. and Heinlein, C. "Taking Information Hiding Seriously in an Object Oriented Context," Net.ObjectDays, Erfurt, Germany, 2003, pp. 51-65. (pdf file)
[7] Keedy, J.L., Heinlein, C. and G. Menger, G. "Reuse Variables: Reusing Code and State in Timor," 8th International Conference on Software Reuse, ICSR 2004, Madrid, 2004, Lecture Notes in Computer Science 3107, Springer Verlag, Berlin, pp. 205-214
[8] Keedy, J.L., Menger, G. and Heinlein, C. "Inheriting Multiple and Repeated Parts in Timor," Journal of Object Technology (www.jot.fm), 2004, vol. 3, no. 10, pp. 99-120. See http://www.jot.fm/issues/issue_2004_11/article1
[9] Keedy, J.L., Menger, G. and Heinlein, C. "Diamond Inheritance and Attribute Types in Timor," Journal of Object Technology (www.jot.fm), 2004, vol. 3, no. 10, pp. 121-142. See http://www.jot.fm/issues/issue_2004_11/article2
[10] Keedy, J.L., Espenlaub, K., Menger, G., Heinlein, C. and Evered, M. "Statically Qualified Types in Timor," Journal of Object Technology, vol. 4, no. 5, pp. 115-137. See http://www.jot.fm/issues/issue_2005_09/article5.
[11] Keedy, J. L., Espenlaub, K., Menger, G. and Heinlein, C. "Call-out Bracket Methods in Timor," Journal of Object Technology, vol. 5, no. 1, pp.51-67, 2006. See http://www.jot.fm/issues/issue_2006_01/article1
[12] Keedy, J.L., Espenlaub, K., Heinlein, C., Menger, G., Henskens, F. and Hannaford, M. "Support for Object Oriented Transactions in Timor," Journal of Object Technology, to appear March/April 2006.
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)
|
Programming Language Support 
