.hc 2 THE EON/EIFFEL SYSTEM

Many traditional languages allow much freedom in the way source code is
managed. The tools to manipulate such languages are disparate and come
from many sources. Eon/Eiffel is not like this, the structure is rigid
because all the functions of program generation are handled by one
program ( the compiler executive program - eon) and this expects things
to be in a logical system.

Below is a brief introduction to the elements of an Eon/Eiffel system.
As stated earlier, knowledge of Eiffel is required, the following should
be used to put the basic concepts into the context of Eon/Eiffel. Terms
used in the rest of the manual are defined here.

.h 2.1 THE EON/EIFFEL DATABASE

One of the features of Eiffel is its typing system, usage of function calls
and variables are carefully check for correct use. This means that the
compiler must have access to a lot of information about the system being 
produced. To accommodate it's requirements a central database is maintained,
and this provides the central repository of data not only for the compiler
but for the browser and documentation tools.

For more information on the location and maintenance
of the database, see DATABASE

.h 2.2 @{CLASSES}

The building blocks of Eiffel are @{classes}. In Eon/Eiffel one @{class} is
defined per source code file and the name of that @{class} is expected to
match that of the @{class}. This helps the compiler (and the programmer)
locate a @{classes} source code when required. As in the language definition,
a @{class} name must be in upper case letters. The file name should be in
lower case with a file extension of @[.e].

All programs consist of a number of @{classes}, all of which have a specific
relationship to one another. Each program contains one @{class} that
is special because it is the one that is called when the program is first run.
This is know as the @[root] @{class}.

Other @{classes} may be @[descendants] or @[parents] of a given @{class} if 
they are part of that @{classes} inheritance relationship. 

A @{class} may use another @{class} as a variables @[type]. Each will be the 
others @[supplier] or @[client] depending on which way around their
relationship is.

It is the way in which a @{class} is used that determines which of the above
type it is, not anything particular about that @{class}. Thus a @{class} may
be a @[root] in one program but something else in another.


.h 2.3 CLUSTERS

A cluster is the collective term of a group of Eiffel @{classes}. Since it
is a objective of the language that code should be reused, it is 
important that existing code should be easily found. The most basic
step to achieving a well ordered set of source code is to save @{classes}
that have something in common in groups or clusters.

For more information on the way clusters are physically implemented, 
see CLUSTERS. The way clusters are setup and used is described in the
sections EON, LACE, BUILDING A SYSTEM


.h 2.4 AST FILES

Abstract Syntax Trees form a fundamental part of Eon/Eiffel. The 
precise nature of the these is unimportant to the programmer but a 
basic understanding will help in understanding how the system works.

The first phase of the compilation process is to read the source of
a given @{class} and check for basic syntax errors. As the file is read,
the code is read into a tree structure in memory and then transferred to
to a disc file ( the @{class} name with a @[.t] file extension). The second
compiler phase reads this file and extracts the information it requires.
Sections of the tree are stored in the database (currently only code
relevant to pre and post conditions). When the compiler needs to refer
to the source code from an inherited @{class}, it need only access the database.

These sections of the source code are also available to be viewed by
programmers via the browser and documentation tools.

The AST file is not readily viewable and therefore provide a way of
producing @{classes} that can be compiled without the actual source code.
If the .@{e} (class source) file is missing but a .@{t} (AST) is present,
the latter will be used for the compilation.

.h 2.5 DEFINING A SYSTEM

A software project is commonly called a @[system]. This implies that a
number of executable programs are generated from a variety of different
@{classes} drawn from a number of clusters. Given the multiple usage of
@{classes} and clusters we must be able to define how a particular program
is to be generated. This is the job of the @[system description file].
It contains information on how @{classes} are to be assembled. 

Eon/Eiffel's system description file is based on @[Lace] as described in
@[Eiffel: The Language] but is only a small subset of it. Future releases
will see a closer adherence to the standard.


.h 2.6 THE EXECUTIVE COMPILER

The generation of an Eiffel program can be a complex business. The @[Lace]
file must be read, @{classes} located and compiled (if required) and then the
C output compiled and linked. There are several stages to each compilation
and a variety of ways the programmer can customise the output.

All this is handled by a single program called @[eon]. This is know as an
executive compiler because, rather that perform compilation itself, it
calls the appropriate tools when they are needed.


.h 2.7 THE BROWSER

As mentioned above, if a language whose objectives are reliability through
reuse of components it is crucially important that a programmer should be
able to find what components are available. Since all the required
information is stored in the main database, all that is required is a
tool that allows the programmer to either look something up or just
browse through a list of what is available.

For this purpose Eon/Eiffel has a database browser.

Eiffel contains a language structure called @[indexing] that allows the
conciencious programmer to enable others to locate @{classes} via a set
of keys. This information is stored in the database but the current
release of the browser can not make use of it. This deficiency will be
corrected in a future release.


.h 2.8 THE DOCUMENTING TOOLS

When a programmer uses a @{class}, he or she will have little interest in the
actual coding of that @{class} only the way it is to be used and what procedures
are available within it. This is known as the @[interface]. 

A documenting tool called @[short] allows the interface of a @{class} to be
displayed or printed. 
