Preface

Aldor is a programming language that attempts to achieve power through uniformity. Rather than build a language by adding features, we have tried instead to build a language by removing restrictions.

While the design of Aldor emphasizes generality and composibility, it also emphasizes efficiency. Usually these objectives seem to pull in different directions. An achievement of Aldor's implementation is its ability to attain both simultaneously.

Bringing Aldor from a gleam in the mind's eye to a concrete working compiler has been a substantial task. Considerable inference and optimization is required to reduce source programs to efficient machine code. For this first release, the source of the compiler is approximately 135,000 lines of code, not including the run-time system, base library and other associated software.

At the beginning of a project such as this, the first steps are tentative and experimental. The next steps get easier as the bootstrapping process completes. Then, as more components fall into place, the forward progress accelerates. We have now reached a point in the development where the rate at which new functionality is coming to life has become almost addictive. There are many directions in which we are eager to continue making improvements to Aldor, but, standing back, we see that these improvements are of secondary importance compared to making the software available. These are some of the projects which were underway at the time this version of Aldor was frozen:

  • Conversion of the AXIOM library: One of the principle tasks ahead is the conversion of the AXIOM library into Aldor. The new language capabilities can allow the AXIOM library to become much more modularized, while providing the additional benefit of allowing AXIOM library functions to be linked directly into C or Fortran based applications.

  • Conversion of the AXIOM library: One of the principle tasks ahead is the conversion of the AXIOM library into Aldor. The new language capabilities can allow the AXIOM library to become much more modularized, while providing the additional benefit of allowing AXIOM library functions to be linked directly into C or Fortran based applications.

  • Interfaces: Direct function calls between Aldor and C work nicely, but we wish to make importing from C++ classes and Fortran common blocks more natural.

  • Exception handling: All the machinery for exception handling is in place beneath the surface of the present implementation, just waiting to be connected to a top-level syntax.

  • Rounded arithmetic: Rounded floating point arithmetic operations have been added to the abstract machine definition. These will be useful for efficient interval arithmetic, among other things. Code generation for these operations, however, will not be part of the first release.

  • Parameterized floating point systems: The arbitrary precision floating point model we wish to present is that of a parameterized floating point system, where the precision, exponent range, etc. are properties of the type of a variable rather than properties of its value. This should allow smooth transition between hardware and software floating point representations on many platforms, and provide a well-defined model for numerical analysis of extended precision computations. Presently, the Float type provides a model in which the precision is carried as part of the value.

  • Extensions: We wish to structure the base Aldor library to use post facto type extensions more thoroughly. This will allow the abstract machine types to be extended to the basic arithmetic types, and extended further with elementary functions, etc.

    The list goes on. The above projects, which are not part of the first release, are compatible upward extensions. As well as these, several other interesting experimental projects are under way.

    The creation of Aldor has involved many people over a period of several years. We wish to express our thanks to everyone who has helped along the way -- in particular, to:

    Shmuel Winograd and Richard Jenks of the Mathematical Sciences
    Department at IBM Research for their continual support from the beginning of this project -- without the environment they fostered this work would not have been possible;

    Barry Trager for his implementation of the interoperability code which allows the AXIOM and Aldor run-time systems to cooperate, and for contributions to chapter 18, Richard Jenks for writing a translator that converts source files written in the AXIOM Version 1 language to Aldor files, and Tim Daly and Richard Jenks for other modifications to the AXIOM system which allow Aldor libraries to be understood;

    Robert Corless and Tim Daly for supplying tutorial chapters incorporated within this Guide -- we hope that this material will help mitigate those blind spots from which we, as developers, inevitably suffer;

    Michael Richardson for his invaluable editorial assistance in the preparation of this guide;

    Knut Wolf and Gerald Baumgartner for their contributions to the present compiler while short-term visitors at Yorktown, and Florian Bundshuh, Bill Burge, Marc Gaetano, Stephen Gortler, Michael Monagan and Simon Robinson for their contributions to earlier, experimental versions of the system;

    Tony Kennedy for porting Aldor to VMS and Dave Bayer for porting Aldor to Macintosh System 7 -- while both of these ports are still quite rough, this experience has already been very useful in refining the portability aspects of the software;

    Manuel Bronstein, George Corliss, Tim Daly, Robert Edwards, Patrizia Gianni, Tony Kennedy, Larry Lambe, Philip Santas and Barry Trager for their patience in dealing with early versions of the software and their many useful bug reports and suggestions;

    and, finally, Brian Ford, Stephen Hague, Themos Tsikas and colleagues at NAG, and Marshall Schor and Roy Adler at IBM, for their help in bringing Aldor out of the laboratory and into the real world.

    Yorktown Heights, New YorkSMW
    September, 1994