Language Issues for Ada's Future

S. Tucker Taft


Unlike Ada 83, Ada 95 from its beginning established itself as a language that is alive and evolving. The increased interconnectedness of the community provided by the internet in general, and "comp.lang.ada" and "Team-Ada" in specific, has created an active forum to propose and discuss language enhancements. The availability of an open-source implementation of the language has also enabled experimentation in ways that were never viable for Ada 83. Finally, the growth in interest in the Java virtual machine has created a new and different kind of platform for Ada, which has in turn created additional pressures to evolve the language to better fit this new kind of "target."

As we celebrate the 5th anniversary of Ada 95, the standard ISO process encourages us to start thinking about possible "official" amendments to the standard, over and above the kinds of forays made during the past 5 years by various individual vendors. But the critical question is: "in what direction do we want Ada to evolve"? At this point in the process, it is premature to give a full answer to this question, but I think I can safely provide some agreed-upon guidelines, plus propose a few more controversial possibilities.

First of all, Ada should remain an inherently "safe" language. New features should not open up gaps in the Ada safety net, and if anything, ways of plugging known gaps should be investigated. Some of this "plugging" of gaps will probably be done via the definition of additional pragmas that provide programmers with new ways to catch potential errors at compile-time. For example, a set of pragmas have been proposed to help minimize the chance of unintentional overriding, (or non-overriding) of primitive operations, due to misspellings, wrong types, missing or extra parameters, etc. As another example, to match semantics required by the Java virtual machine, a useful standard pragma would be one that disallows local variables not initialized before use on all paths. A third place where pragmas might help is with "units" checking (e.g. length, mass, time), where appropriate pragmas (and/or attributes) could be used to associated units with particular subtypes of a given type, and programs that violate the normal rules about units compatibility would be rejected. A fourth obvious candidate for pragma-based enhancement is in the area of assertions and user-defined invariants. At a bare minimum, the "Assert" pragma needs standardization. These kinds of enhancements work well as pragmas, as they only require that the compiler reject otherwise legal programs. They don't introduce any new dynamic semantics.

A second important thrust for Ada's future is enhanced interoperability with other languages, in particular Java, C, and C++. For interoperability with Java, probably the most important enhancement relates to types with cyclic dependences that cross package boundaries. A second important area has to do with the limited kind of multiple inheritance provided by Java, namely multiple "interface" inheritance. Both of these are likely to require syntactic and semantic extensions to the language, and (like marriage!) should not be entered into lightly or inadvisedly.

A third important thrust is focused on enhanced portability across the popular operating systems of today (Unix, Linux, Windows, and MacOS). For improved portability, an additional set of standard packages is probably the most effective solution. Already, a standard package for filesystem "directory" operations has been proposed, based largely on "Posix" capabilities known to be supportable on all interesting systems. Other packages addressing features such as environment variables, TCP/IP sockets, timezones, etc. might also be appropriate candidates for standardization at this point. Certainly anything needed to create portable "server" programs in Ada would seem to be worth considering, as the world moves toward a thin-client, shared server environment.

The final area I would like to discuss are changes to the language to lower the entry barrier to practitioners coming from other languages, or from modeling languages like UML. I have already mentioned Java's multiple "interface" inheritance as a feature to be investigated for better integration with Ada. This kind of interface inheritance is also being provided by Microsoft's new ".Net" runtime, and by its new "C#" language. More controversial would be to support some kind of Object'Operation syntax, to eliminate some of the verbosity and redundancy associated with the object-oriented style of programming when using Ada. There are also certain issues relating to excessive access type conversions that would also fall in this area of lowering the entry barrier to other O-O practitioners.

Clearly these kinds of amendments are more controversial than the other types already discussed. From a philosophical point of view, why should Ada worry about what other languages are doing? One reason is to remove impediments to "infiltration" of Ada into an organization. With the loss of the DoD mandate, Ada needs to be a language that can move into an organization form the bottom, or the side, rather than from the top. This implies focusing on the ease of moving from other popular languages to Ada, and the ease of integration of Ada components with components written in other languages, especially on top of the Java virtual machine, or the new Microsoft .Net runtime.

The other reason to look at other languages is to assess whether certain topics we rejected during the Ada 9X process, as not having a clear "natural" answer, can now be tackled with more confidence. Certainly multiple inheritance as practiced by C++ represents a horrendously complex mechanism, with dubious payoff. On the other hand, the relatively light weight interface inheritance provided by Java, C#, CORBA, etc., has emerged over the past 5 years as an appropriate compromise between the simplicity of single inheritance, and the flexibility of full multiple inheritance.

A final reason to look at other languages is that essentially all new development is now being done in O-O languages. In the past 5 years, O-O has established itself as the basic programming paradigm for the whole industry. Additional tools and modeling languages (e.g. the UML) have appeared that presume a particular flavor of O-O that is represented by the Object.Operation model of the world. Although this model is not as flexible as the symmetric model used by Ada 95 and Common Lisp, it does have its advantages for many kinds of O-O systems, and allows the programmer to focus less on the package/module where a type is defined, and more on the object being manipulated.

I believe we need to look at Ada from both a technical perspective and a marketing perspective, and be sure that the language enhancements we invest in not only improve the language technically, but also make it easier for non-Ada programmers to understand and to adopt.