day@grand.UUCP (Dave Yost) (12/22/88)
From: Bertrand Meyer <bertrand@eiffel.COM>
Date: Tue, 8 Nov 88 21:02:22 PST
This is the second of two extracts from Champ-de-Mars, V. 1 n. 4.
EIFFEL: WHAT'S COOKING?
Anyone who thinks the designers of Eiffel are enjoying a
well-earned rest has not visited Santa Barbara recently.
This short survey highlights the major ongoing
developments. We can't tell you everything, especially on
the longer-term projects; however this should help you
figure out what Eiffel will be like in the months and
years to come.
THE SCHEDULE
The current release is 2.1, produced last summer. The
next release, 2.2, will be distributed in early 1989, to
be followed by 2.3 in the summer.
The developments described below are of course
complemented by a constant effort to make the system ever
more efficient in time and space - performance having
been from the beginning a key Eiffel objective -, to
improve the user interface etc. Porting efforts also
continue, targeted at various hardware architectures and
operating systems.
THE LIBRARIES
Much effort has been devoted in the preparation of
release 2.2 to enriching the libraries of reusable
software components, which are such an important
component of the Eiffel approach.
The Basic Library, covering fundamental algorithms and
data structures, is being expanded and reinforced with
implementations of new useful abstractions. Expansion
and reinforcement are also in order for the Graphics
Library, based on the X Window system where available.
Aside from following the avatars of X, the library is
extended with new graphical classes covering more
advanced notions.
2.2 will also include new libraries. Of particular
importance are libraries for parsing and lexical
analysis. The parsing classes, based on pure object-
oriented principles, encapsulate general properties of
the chosen parsing mechanism; then every production in a
grammar will yield a class, heir to one of these basic
classes. The text of such a class is easily deduced from
the corresponding BNF (Backus-Naur Form). Semantic
operations of various kinds are easily integrated in this
framework. As always with Eiffel, multiple inheritance is
fundamental. Lexical analysis classes are also
consistent with object-oriented principles. They are
based on general classes for dealing with finite automata
and regular expressions, also applicable to string
searching (the object-oriented version of the Unix grep).
2
Other new library classes give access to internal
properties of Eiffel classes. This includes in particular
a class E_CLASS; an instance of E_CLASS describes an
Eiffel classes and enable clients to obtain its source
texts, interface (as produced by the short tool of the
Eiffel environment), invariant, list of features
(attributes and routines), lists of heirs, parents,
suppliers and clients, etc. This makes it possible to
write Eiffel tools, such as GOOD (Graphics for Object-
Oriented Design, a tool of the graphical environment) to
index reusable classes and retrieve them based on their
properties.
Classes under development for 2.2 also cover access to
more operating system features (system calls, better file
processing, command-line options etc.)
All the library extensions will be delivered at no extra
cost. As always, no fee is charged on software produced
with Eiffel, libraries included.
THE LANGUAGE
The language design is not expected to undergo any major
change; Eiffel will essentially remain as described in
the current basic reference, Bertrand Meyer's Object-
Oriented Software Construction (Prentice-Hall, 1988).
Some local improvements are in progress, however:
* The type system draws a clear distinction between
simple types (INTEGER, REAL, BOOLEAN, CHARACTER)
and class types. This will remain but some
operations will be generalized so that any Eiffel
class (especially if generic) may be written to
have the same semantics on simple types and class
types. Such operations include Equal, Clone and
other predefined features. Technically, almost no
language change is involved, simply more
consistent conventions.
* Simple types will be formally treated as classes;
for example, INTEGER and REAL will inherit from a
deferred library class NUMBER. Again, this does
not bring any significant change to the language
framework.
* In the same spirit, a universal feature Out will
be introduced; a.Out denotes a readable string
representation of a for a of any type. As Clone
or Equal, Out will be applicable to all types.
* To satisfy terseness-loving programmers, some
syntactical equivalences will be made available,
such as a@i (``a at index i'') as a synonym for
a.entry (i) (array access). Similarly, the
features of class NUMBER, such as plus, will have
infix synonyms: + etc. This brings in a restricted
form of overloading for predefined operators but
3
avoids the syntactic and semantic complexity of
unbridled overloading. a + b and a < b will be
mere syntactical abbreviations for a.plus (b) and
a.lt (b), meaningful if the type of a and b is a
descendant of class NUMBER, say a class VECTOR.
PERSISTENCY, INDEXING,
CONCURRENCY
This survey will conclude with a brief look at some
longer-term developments: better support for persistency;
concurrency; class indexing. In all cases the target is
1989 for a first product, although we will carefully
avoid any more precise commitment (our Cocomo model does
not account for the ``advanced research under way'' cost
factor).
On persistency, the current environment already supports
storage and retrieval of entire object structures,
through the powerful and convenient store and retrieve.
More is needed, however, in making objects individually
persistent. The solution is based on a new library class
ENVIRONMENT, which has other interesting applications.
Another development covers tools for indexing and
retrieving reusable components, using some of the library
classes (such as E_CLASS) mentioned above.
Finally, much effort is devoted to making Eiffel a
concurrent language. We do not want to push YACM (Yet
Another Concurrency Model); better take a low profile and
offer basic facilities which can then be used to build
libraries (monitors, rendez-vous and the like) using such
Eiffel structuring mechanisms as genericity and multiple
inheritance. Also, we want to cater to distributed
systems as well as to multiprocessing. The solution
should be compatible with Eiffel correctness concerns, as
reflected by class invariants and other assertions.
Finally, everything should be in the Eiffel tradition of
simplicity and consistency. We are working hard to ensure
that Eiffel will be the first widely available object-
oriented language with full support for concurrent and
distributed programming.
Stay tuned to future Champ-de-Mars as these various
efforts mature and the results find their way into the
delivered product