Eiffel is an ISO-standardized, object-oriented programming language designed to enable programmers to efficiently develop extensible, reusable, reliable software. Eiffel is used in academia as a language for teaching computer-programming principles. Eiffel is used in the finance, aerospace, health-care, video-gaming, and other industries as a development platform. Since 1985, many suppliers have developed Eiffel programming environments.

The Eiffel language's design is closely connected with the Eiffel programming method. Both are based on a set of principles, including design by contract, command-query separation, uniform-access principle, single-choice principle, open-closed principle, and option-operand separation.

Many concepts initially introduced by Eiffel have later found their way into Java, C#, and other languages. New language-design ideas, particularly through the ECMA/ISO standardization process, continue to be incorporated into the Eiffel language.

Characteristics

The key characteristics of the Eiffel language include:

• An object-oriented program structure in which a class serves as the basic unit of decomposition.
• Design by contract tightly integrated with other language constructs.
• Automatic memory management, typically implemented by garbage collection.
• Inheritance, including multiple inheritance, renaming, redefinition, "select", non-conforming inheritance, and other mechanisms intended to make inheritance safe.
• Constrained and unconstrained generic programming.
• A uniform type system handling both value and reference semantics in which all types, including basic types such as INTEGER, are class-based.
• Type safety (static typing).
• Void safety, or static protection against calls on null references, through the attached-types mechanism.
• Agents, or objects that wrap computations, closely connected with closures and lambda calculus.
• Once routines, or routines evaluated only once, for object sharing and decentralized initialization.
• Keyword-based syntax in the ALGOL/Pascal tradition but separator-free, insofar as semicolons are optional, with operator syntax available for routines.
• Case insensitivity.

Design goals

Eiffel shuns coding tricks or coding techniques intended as optimization hints to the compiler. The aim is not only to make the code more readable, but also to allow programmers to concentrate on the important aspects of a program without getting bogged down in implementation details. Eiffel's simplicity is intended to promote simple, extensible, reusable, and reliable answers to computing problems. Compilers for computer programs written in Eiffel provide extensive optimization techniques, such as automatic in-lining, that relieve the programmer of part of the optimization burden while producing code whose efficiency is comparable to that of code written in C++.

Background

The design goal behind the Eiffel language, libraries, and programming methods is to enable programmers to create reliable, reusable software modules. Eiffel supports multiple inheritance, genericity, polymorphism, encapsulation, type-safe conversions, and parameter covariance. Eiffel's most important contribution to software engineering is design by contract (DbC), in which assertions, preconditions, postconditions, and class invariants are employed to help ensure program correctness without sacrificing efficiency.

Eiffel's design is based on object-oriented programming theory, with only minor influence of other paradigms or concern for support of legacy code. Eiffel formally supports abstract data types. Under Eiffel's design, a software text should be able to reproduce its design documentation from the text itself, using a formalized implementation of the "Abstract Data Type".

Implementations and environments

EiffelStudio is an integrated development environment available under either an open source or a commercial license. It offers an object-oriented environment for software engineering. EiffelEnvision is a plug-in for Microsoft Visual Studio that allows users to edit, compile, and debug Eiffel projects from within the Microsoft Visual Studio IDE. EiffelStudio and EiffelEnvision are free for non-commercial use. Four other open source implementations are available: "The Eiffel Compiler" tecomp, Gobo Eiffel, SmartEiffel—the GNU implementation, based on an older version of the language—and Visual Eiffel.

Several other programming languages incorporate elements first introduced in Eiffel. Sather, for example, was originally based on Eiffel but has since diverged, and now includes several functional programming features. The interactive-teaching language Blue, forerunner of BlueJ, is also Eiffel-based. The Apple Media Tool includes an Eiffel-based Apple Media Language.

Specifications and standards

The Eiffel language definition is an international standard of the ISO. The standard was developed by ECMA International, which first approved the standard on 21 June 2005 as ECMA standard 367, Eiffel: Analysis, Design and Implementation Language. In June 2006, ECMA and ISO adopted the second version. In November 2006, ISO first published that version. The standard can be found and used free of charge on the ECMA site. The ISO version is identical in all respects except formatting.

Eiffel Software, "The Eiffel Compiler" tecomp and Eiffel-library-developer Gobo have committed to implementing the standard; Eiffel Software's EiffelStudio 6.1 implements some of the major new mechanisms—in particular, inline agents, assigner commands, bracket notation, non-conforming inheritance, and attached types. The SmartEiffel team has turned away from this standard to create its own version of the language, which they believe to be closer to the original style of Eiffel. Object Tools has not disclosed whether future versions of its Eiffel compiler will comply with the standard.

The standard cites the following, predecessor Eiffel-language specifications:

• Bertrand Meyer: Eiffel: The Language, Prentice Hall, second printing, 1992 (first printing: 1991)
• Bertrand Meyer: Standard Eiffel (revision of preceding entry), ongoing, 1997-present, at Bertrand Meyer's ETL3 page, and
• Bertrand Meyer: Object-Oriented Software Construction, Prentice Hall: first edition, 1988; second edition, 1997.

Syntax and semantics

Overall structure

A class contains features, which are similar to "members", "attributes" or "methods" in other object-oriented programming languages. A class also defines its invariants, and contains other properties, such as a "notes" section for documentation. Eiffel's standard data types, such as ARRAY are all themselves classes, and collections are modified and accessed via features rather than special syntax. Moreover, unlike some "impure" object-oriented languages like Java, Eiffel eschews "basic data types" outside of its class system.

Every system must have a class designated as "root", with one of its creation procedures designated as "root procedure". Executing a system consists of creating an instance of the root class and executing its root procedure. Generally, doing so creates new objects, calls new features, and so on.

Eiffel has six basic executable instructions: assignment; object creation; routine call; conditional; iteration; and choice. Eiffel's control structures are strict in enforcing structured programming: every block has exactly one entry and exactly one exit.

Scoping

Unlike many object-oriented languages, but like Smalltalk, Eiffel does not permit any assignment into fields of objects, except within the features of an object. Eiffel emphasizes information hiding and data abstraction, by requiring formal interfaces to data mutation. To put it in the language of other object-oriented programming languages, all Eiffel fields are "private", and "setters" are needed to modify values. An upshot of this is that "setters" can, and normally do, implement the invariants Eiffel provides syntax for.

"Hello, world!"

   HELLO_WORLD

   make

   make

       do

           print ("Hello, world!%N")

       end

Design by Contract

• Routine precondition: The precondition may only be weakened by inheritance; any call that meets the requirements of the ancestor meets those of the descendant.
• Routine postcondition: The postcondition can only be strengthened by inheritance; any result guaranteed by the ancestor is still provided by the descendant.
• Class invariant

In addition, the language supports a "check instruction" (a kind of "assert") and loop invariants.

Features, commands, queries

The command-query distinction is important to the Eiffel method. In particular:

• Uniform-Access Principle: from the point of view of a software client making a call to a class feature, whether a query is an attribute (field in each object) or a function (algorithm) should not make any difference. For example a_vehicle.speed could be an attribute, accessed from the object's representation; or it could be computed by a function that divides distance by time. The notation is the same in both cases, so that it's easy to change representation without affecting the rest of the software.
• Command-Query Separation Principle: Queries must not modify the instance. This is not a language rule but a methodological principle. So in good Eiffel style, one does not find "get" functions that change something and return a result; instead there are commands (procedures) to change objects, and queries to obtain information about the object, resulting from preceding changes.

Overloading

This design choice helps the readability of classes, by avoiding a cause of ambiguity about which routine will be invoked by a call. It also simplifies the language mechanism; in particular, this is what makes Eiffel's multiple inheritance mechanism possible.

Names can, of course, be reused in different classes. For example the "+" operator is defined in several classes: INTEGER, REAL, STRING, etc.

Genericity

It is also possible to have 'constrained' formal parameters, for which the actual parameter must inherit from a given class, the "constraint". For example in

  class HASH_TABLE [G, KEY -> HASHABLE]

Inheritance basics

  A

  B

-- ... Rest of class declaration ... The class may redefine (override) some or all of the inherited features. This must be explicitly announced at the beginning of the class through a redefine subclause of the inheritance clause, as in class C inherit

   A

       redefine f, g, h end

   B

       redefine u, v end

Deferred classes and features

Classes may be defined with deferred class rather than with class to indicate that the class may not be directly instantiated. Non-instantiatable classes are called abstract classes in some other object-oriented programming languages. In Eiffel parlance, only an "effective" class can be instantiated (it may be a descendent of a deferred class). A feature can also be deferred by using the deferred keyword in place of a do clause. If a class has any deferred features it must be declared as deferred; however, a class with no deferred features may nonetheless itself be deferred.

Deferred classes play some of the same role as interfaces in languages such as Java, though many object-oriented programming theorists believe interfaces are themselves largely an answer to Java's lack of multiple inheritance (which Eiffel has).

Renaming

Tuples

  TUPLE [name: STRING; weight: REAL; date: DATE]

  ["Brigitte", 3.5, Last_night]

Thanks to the notion of assigner command (see below), dot notation can also be used to assign components of such a tuple, as in

  t.weight := t.weight + 0.5

The precise specification of e.g. TUPLE [A, B, C] is that it describes sequences of at least three elements, the first three being of types A, B, C respectively. As a result TUPLE [A, B, C] conforms to (may be assigned to) TUPLE [A, B], to TUPLE [A] and to TUPLE (without parameters), the topmost tuple type to which all tuple types conform.

Agents

For example, to execute the my_action block for each element of my_list, one would write:

  my_list.do_all (agent my_action)

  my_list.do_if (agent my_action, agent my_condition)

  a.call ([x])

It is possible to keep some arguments to an agent open and make others closed. The open arguments are passed as arguments to call: they are provided at the time of agent use. The closed arguments are provided at the time of agent definition. For example, if action2 has two arguments, the iteration

  my_list.do_all (agent action2 (?, y))

The distinction between open and closed operands (operands = arguments + target) corresponds to the distinction between bound and free variables in lambda calculus. An agent expression such as action2 (?, y) with some operands closed and some open corresponds to a version of the original operation curried on the closed operands.

The agent mechanism has been recently generalized to allow defining an agent without reference to an existing routine (such as my_action, my_condition, action2), through inline agents as in my_list.do_all (agent (s: STRING)

    require

        not_void: s /= Void

    do

        s.append_character (',')

    ensure

        appended: s.count = old s.count + 1

    end)

  my_list.for_all (agent (x: INTEGER): BOOLEAN do Result := (x > 0) end)

Once routines

   once

       create Result.make (args)

            -- This creates the object and returns a reference to it through `Result'.

   end

Often "once routines" perform a required initialization: multiple calls to a libraries can include a call to the initialization procedure, but only the first such call will perform the required actions. Using this pattern initialization can be decentralized, avoiding the need for a special initialization module. "Once routines" are similar in purpose and effect to the singleton pattern in many programming languages, and to the Borg pattern used in Python.

The ECMA specification allows variants of "once" (qualified by a keyword in parentheses, e.g. once (THREAD): once per process, once per thread, once per object. However, this is not yet fully implemented by current compilers (typically, only PROCESS and THREAD).

Conversions

(Conversion principle) A type may not both conform and convert to another.

For example NEWSPAPER may conform to PUBLICATION, but INTEGER converts to REAL (and does not inherit from it).

The conversion mechanism simply generalizes the ad hoc conversion rules (such as indeed between INTEGER and REAL) that exist in most programming languages, making them applicable to any type as long as the above principle is observed. For example a DATE class may be declared to convert to STRING; this makes it possible to create a string from a date simply through

  my_string := my_date

  create my_string.make_from_date (my_date)

As another example, if there is such a conversion procedure listed from TUPLE [day: INTEGER; month: STRING; year: INTEGER], then one can directly assign a tuple to a date, causing the appropriate conversion, as in

     Bastille_day := [14, "July", 1789]

Exception handling

An Eiffel exception handler is defined using the rescue keyword. Within the rescue section, the retry keyword executes the routine again. For example, the following routine tracks the number of attempts at executing the routine, and only retries a certain number of times: connect_to_server (server: SOCKET)

     -- Connect to a server or give up after 10 attempts.

   require

       server /= Void and then server.address /= Void

   local

       attempts: INTEGER

   do

       server.connect

   ensure

     connected: server.is_connected

   rescue

       if attempts < 10 then

           attempts := attempts + 1

           retry

       end

   end

This example is arguably flawed for anything but the simplest programs, however, because connection failure is to be expected. For most programs a routine name like attempt_connecting_to_server would be better, and the postcondition would not promise a connection, leaving it up to the caller to take appropriate steps if the connection was not opened.

Concurrency

Operator and bracket syntax, assigner commands

Eiffel's view of computation is completely object-oriented in the sense that every operation is relative to an object, the "target". So for example an addition

 [1] a + b

 [2] a.plus (b)

Of course [1] is the conventional syntax and usually preferred. Operator syntax makes it possible to use either form by declaring the feature (for example in INTEGER, but this applies to other basic classes and can be used in any other for which such an operator appropriate): plus alias "+" (other: INTEGER): INTEGER

       -- ... Normal function declaration...

   end

Every class may in addition have one function aliased to "[]", the "bracket" operator, allowing the notation a [i, ...] as a synonym for a.f (i, ...) where f is the chosen function. This is particularly useful for container structures such as arrays, hash tables, lists etc. For example access to an element of a hash table with string keys can be written

  number := phone_book ["JILL SMITH"]

     -- The element of key `key'.

     -- ("Getter" query)

   do

       ...

   end

put (e: ELEMENT; key: STRING)

     -- Insert the element `e', associating it with the key `key'.

     -- ("Setter" command)

   do

       ...

   end

  [4] phone_book.put (New_person, "JILL SMITH")

  [5] phone_book ["JILL SMITH"] := New_person

  item alias "[]" (key: STRING): ELEMENT assign put

note: The argument list of a's assigner is constrained to be: (a's return type;all of a's argument list...)

Lexical and syntax properties

Comments are introduced by -- (two consecutive dashes) and extend to the end of the line.

The semicolon, as instruction separator, is optional. Most of the time the semicolon is just omitted, except to separate multiple instructions on a line. This results in less clutter on the program page.

There is no nesting of feature and class declarations. As a result the structure of an Eiffel class is simple: some class-level clauses (inheritance, invariant) and a succession of feature declarations, all at the same level.

It is customary to group features into separate "feature clauses" for more readability, with a standard set of basic feature tags appearing in a standard order, for example: class HASH_TABLE [ELEMENT, KEY -> HASHABLE] inherit TABLE [ELEMENT]

   feature -- Initialization

        -- ... Declarations of initialization commands (creation procedures/constructors) ...

   feature -- Access

        -- ... Declarations of non-boolean queries on the object state, e.g. item ...

   feature -- Status report

        -- ... Declarations of boolean queries on the object state, e.g. is_empty ...

   feature -- Element change

        -- ... Declarations of commands that change the structure, e.g. put ...

   -- etc.

Style conventions

Much of the documentation of Eiffel uses distinctive style conventions, designed to enforce a consistent look-and-feel. Some of these conventions apply to the code format itself, and others to the standard typographic rendering of Eiffel code in formats and publications where these conventions are possible.

While the language is case-insensitive, the style standards prescribe the use of all-capitals for class names (LIST), all-lower-case for feature names (make), and initial capitals for constants (Avogadro). The recommended style also suggests underscore to separate components of a multi-word identifier, as in average_temperature.

The specification of Eiffel includes guidelines for displaying software texts in typeset formats: keywords in bold, user-defined identifiers and constants are shown in italics, comments, operators, and punctuation marks in Roman, with program text in blue as in the present article to distinguish it from explanatory text. For example, the "Hello, world!" program given above would be rendered as below in Eiffel documentation:

class

    HELLO_WORLD

create

    make

feature

   make

      do

         print ("Hello, world!")

      end

end

Interfaces to other tools and languages

It is possible for example to program machine- and operating-system level operations in C. Eiffel provides a straightforward interface to C routines, including support for "inline C" (writing the body of an Eiffel routine in C, typically for short machine-level operations).

Although there is no direct connection between Eiffel and C, many Eiffel compilers except one (Visual Eiffel) output C source code as an intermediate language, to submit to a C compiler, for optimizing and portability. The Eiffel Compiler tecomp can execute Eiffel code directly (like an interpreter) without going via an intermediate C code or emit C code which will be passed to a C compiler in order to obtain optimized native code. On .NET, the EiffelStudio compiler directly generates CIL (Common Intermediate Language) code. The SmartEiffel compiler can also output Java bytecode.

References