wsmith@m.cs.uiuc.edu (12/09/88)
I would like to contrast two desirable properties of a language: the property that software in the language is reusable, with the property that the software is easily rewriteable so that designs are reusable. I believe both are desirable, but may conflict with each other. To me, reusable software means that implementations may be used for many different purposes. It may be difficult to make the first implementation or the language may have a steep learning curve (as I understand Smalltalk does to an extent) but once it is done, you have an library that may save effort in the future. Another desirable property to me is that the software is rewritable. For this to be true, the effort reused is in the design phase. A design may be implemented in several different ways and each of the effort to make new implementations of the design would be painless in a language with this property. If a algorithm is easy to implement, reimplement, or modify in a language, there are several benefits to be gained: A library of designs may be created that may then be adapted to different uses, which leads to the second point: I think it is easier to reuse designs than implementations. If I have a simple schema (design) for symbol tables and I need to use that design in a slightly different manner for a prototype, it could be much easier to reimplement the modified design than to try to fit an existing C++ or Smalltalk implementation into my new framework. Prototyping will be much easier. The work of making a prototype is to convert a design into a cheap and dirty implementation. By making programs easily implementable, that initial expense is minimized. Later, the same design may be implemented in a more sophisticated manner as profiling and performance monitors indicate that improvements are necessary. At the point where implementation becomes easy enough, a higher level implementation language could be used to guide an automatic generator of lower level code. I believe it will be difficult to develop a language where both reusable designs and reusable code are possible. The problem is capturing all possible modification to a design and mapping them onto parameterizations of a library. At some point, a modified design will force a reimplementation of the library. Unless the reimplementation is made easy, the design won't be very reusable. The effort needed to make code reusable inhibits this goal. Bill Smith wsmith@cs.uiuc.edu uiucdcs!wsmith
dts@lfcs.ed.ac.uk (Don Sannella) (12/21/88)
Have a look at the modularization facilities in the Standard ML programming language. These allow large programs to be structured into modules with explicitly-specified interfaces. Interfaces (called signatures) and their implementations (called structures) are defined separately. Every structure has an signature, but a given signature can describe lots of different structures. Structures may be built on top of existing structures in a hierarchical way, and the signature reflects this. It is possible to define parameterized structures, called functors. A functor is like a function on the level of structures. Each functor has an input signature describing structures to which it may be applied, and an output signature describing the result of an application. For more information, see the references below. These are just what you want for reusability. I can't explain this adequately in a few lines though -- you have to look at some examples. Functors are generic program components, and the explicit interfaces take care of putting programs together from these components. You can alter implementations as you like; provided the new implementation fits the interface, everything is fine. Don Sannella University of Edinburgh References: Robert Harper. Introduction to Standard ML. Report ECS-LFCS-86-14, University of Edinburgh (1986). This is an excellent informal introduction to the language, including the modules facilities, with examples. This is available from the Computer Science Department, Univ. of Edinburgh, Edinburgh EH9 3JZ Scotland, but it costs 5 pounds. David MacQueen. Modules for Standard ML. Proc. ACM Symp. on LISP and Functional Programming, Austin (1984). An early version of the modules facilities. A bit hard to read, but maybe easier to get your hands on than the report by Harper. Ake Wikstrom. Functional Programming using Standard ML. Prentice-Hall (1987). This textbook is based on ML but doesn't include anything about modules unfortunately. Don Sannella and Lincoln Wallen. A calculus for the construction of modular Prolog programs. Proc. 1987 IEEE Symp. on Logic Programming, San Francisco. This is what you get if you apply the same ideas to Prolog.