Eiffel Analysis, Design and Programming Language ECMA-367
Total Page:16
File Type:pdf, Size:1020Kb
ECMA-367 1st Edition / June 2005 Eiffel Analysis, Design and Programming Language Standard ECMA-367 1st Edition - June 2005 Eiffel Analysis, Design and Programming Language Ecma International Rue du Rhône 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org Brief history Eiffel was originally designed, as a method of software construction and a notation to support that method, in 1985. The first implementation, from Eiffel Software (then Interactive Software Engineering Inc.), was commercially released in 1986. The principal designer of the first versions of the language was Bertrand Meyer. Other people closely involved with the original definition included Jean-Marc Nerson. The language was originally described in Eiffel Software technical documents that were expanded to yield Meyer’s book Eiffel: The Language in 1990-1991. The two editions of Object-Oriented Software Construction (1988 and 1997) also served to describe the concepts. (For bibliographical references on the documents cited see 3.6.) As usage of Eiffel grew, other Eiffel implementations appeared, including Eiffel/S and Visual Eiffel from Object Tools, Germany, EiffelStudio and Eiffel Envision from Eiffel Software, and SmartEiffel from LORIA, France. Eiffel today is used throughout the world for industrial applications in banking and finance, defense and aerospace, health care, networking and telecommunications, computer-aided design, game programming, and many other application areas. Eiffel is particularly suited for mission-critical developments in which programmer productivity and product quality are essential. In addition Eiffel is a popular medium for teaching programming and software engineering in universities. In 2002 Ecma International formed Technical Group 4 (Eiffel) of Technical Committee 39 (Programming and Scripting Languages). The Eiffel Analysis, Design and Programming Language Standard provides a precise definition of the language and ensures interoperability between implementations. The first of these benefits is of particular interest to implementors of Eiffel compilers and environments, who can rely on it as the reference on which to base their work; the second, to Eiffel users, for whom the Standard delivers a guarantee of compatibility between the products of different providers and of trust in the future of Eiffel. TG4 devised this Standard from June 2002 to April 2005, starting from material from the original and revised versions of the book Standard Eiffel (latest revision of Eiffel: The Language). During that period the Technical Group conducted fifteen face-to-face meetings and numerous phone meetings, in addition to extensive technical correspondence. The members of the committee have been: Karine Arnout (ETH, Zurich); Éric Bezault (Axa Rosenberg, Orinda); Paul Cohen (Generic, Stockholm), Dominique Colnet (LORIA, Nancy); Mark Howard (Axa Rosenberg, Orinda); Alexander Kogtenkov (Eiffel Software, Moscow); Bertrand Meyer (Eiffel Software, Santa Barbara, and ETH, Zurich); Christine Mingins (Monash University, Melbourne); Roger Osmond (EMC, Boston); Emmanuel Stapf (Eiffel Software, Santa Barbara); Kim Waldén (Generic, Stockholm). Observers having attended one or more of the meetings include Cyril Adrian (LORIA), Volkan Arslan (ETH), Paul Crismer (Groupe S, Brussels), Jocelyn Fiat (Eiffel Software, France), Randy John (Axa Rosenberg), Ian King (Eiffel Software), Philippe Ribet (LORIA), Julian Rogers (Eiffel Software), Bernd Schoeller (ETH), David Schwartz (Axa Rosenberg), Zoran Simic (Axa Rosenberg), Raphael Simon (Eiffel Software), Olivier Zendra (LORIA). The committee acknowledges the contributions of many people including David Hollenberg, Marcel Satchell, Richard O’Keefe and numerous others listed in the acknowledgments of the book Standard Eiffel. The editor of the standard is Bertrand Meyer. Emmanuel Stapf is the convener of TG4 (succeeding Christine Mingins, 2002-2003) and its secretary (succeeding Karine Arnout, 2002-2004). The final version of the document was prepared by Éric Bezault, Mark Howard, Alexander Kogtenkov, Bertrand Meyer and Emmanuel Stapf. This Ecma Standard has been adopted by the General Assembly of June 2005. Table of contents 1 Scope 1 1.1 Overview 1 1.2 “The Standard” 1 1.3 Aspects covered 1 1.4 Aspects not covered 1 2 Conformance 1 2.1 Definition 1 2.2 Compatibility and non-default options 2 2.3 Departure from the Standard 2 3 Normative references 2 3.1 Earlier Eiffel language specifications 2 3.2 Eiffel Kernel Library 2 3.3 Floating point number representation 2 3.4 Character set: Unicode 3 3.5 Character set: ASCII 3 3.6 Phonetic alphabet 3 4 Definitions 3 5 Notational conventions 3 5.1 Standard elements 3 5.2 Normative elements 3 5.3 Rules on definitions 3 5.4 Use of defined terms 4 5.5 Unfolded forms 4 5.6 Language description 4 5.7 Validity: “if and only if” rules 4 6 Acronyms and abbreviations 5 6.1 Name of the language 5 6.2 Pronunciation 5 7 General description 5 7.1 Design principles 5 7.2 Object-oriented design 6 7.3 Classes 6 7.4 Types 10 - i - 7.5 Assertions 11 7.6 Exceptions 13 7.7 Genericity 14 7.8 Inheritance 15 7.9 Polymorphism and dynamic binding 17 7.10 Combining genericity and inheritance 18 7.11 Deferred classes 20 7.12 Tuples and agents 21 7.13 Type- and void-safety 22 7.14 Putting a system together 23 8 Language specification 23 8.1 General organization23 8.2 Syntax, validity and semantics 24 8.2.1 Definition: Syntax, BNF-E 24 8.2.2 Definition: Component, construct, specimen 24 8.2.3 Construct Specimen convention 24 8.2.4 Construct Name convention 24 8.2.5 Definition: Terminal, non-terminal, token 24 8.2.6 Definition: Production 25 8.2.7 Kinds of production 25 8.2.8 Definition: Aggregate production 25 8.2.9 Definition: Choice production 25 8.2.10 Definition: Repetition production, separator 25 8.2.11 Basic syntax description rule 26 8.2.12 Definition: Non-production syntax rule 26 8.2.13 Textual conventions 26 8.2.14 Definition: Validity constraint 27 8.2.15 Definition: Valid 27 8.2.16 Validity: General Validity rule 27 8.2.17 Definition: Semantics 27 8.2.18 Definition: Execution terminology 27 8.2.19 Semantics: Case Insensitivity principle 28 8.2.20 Definition: Upper name, lower name 28 8.2.21 Syntax (non-production): Semicolon Optionality rule 28 8.3 The architecture of Eiffel software 29 8.3.1 Definition: Cluster, subcluster, contains directly 29 8.3.2 Definition: Terminal cluster, internal cluster 29 8.3.3 Definition: Universe 30 8.3.4 Validity: Class Name rule 30 8.3.5 Semantics: Class name semantics 30 8.3.6 Definition: System, root type name, root procedure name 30 8.3.7 Definition: Type dependency 30 8.3.8 Validity: Root Type rule 31 - ii - 8.3.9 Validity: Root Procedure rule 31 8.3.10 Definition: Root type, root procedure, root class 31 8.3.11 Semantics: System execution 32 8.3.12 Syntax : Class names 32 8.4 Classes 32 8.4.1 Definition: Current class 32 8.4.2 Syntax : Class declarations 32 8.4.3 Syntax : Notes 32 8.4.4 Semantics: Notes semantics 33 8.4.5 Syntax : Class headers 33 8.4.6 Validity: Class Header rule 33 8.4.7 Definition: Deferred class, effective class 33 8.4.8 Syntax : Obsolete marks 33 8.4.9 Semantics: Obsolete semantics 33 8.5 Features 34 8.5.1 Definition: Inherited, immediate; origin; redeclaration; introduce 34 8.5.2 Syntax : Feature parts 34 8.5.3 Feature categories: overview 34 8.5.4 Syntax : Feature declarations 35 8.5.5 Syntax : New feature lists 35 8.5.6 Syntax : Feature bodies 35 8.5.7 Validity: Feature Body rule 35 8.5.8 Definition: Variable attribute 36 8.5.9 Definition: Constant attribute 36 8.5.10 Definition: Routine, function, procedure 36 8.5.11 Definition: Command, query 37 8.5.12 Definition: Signature, argument signature of a feature 37 8.5.13 Feature principle 37 8.5.14 Syntax : Feature names 37 8.5.15 Syntax (non-production): Alias Syntax rule 38 8.5.16 Definition: Operator feature, bracket feature 38 8.5.17 Definition: Identifier of a feature name 38 8.5.19 Definition: Same feature name, same operator, same alias 39 8.5.20 Syntax : Operators 39 8.5.21 Validity: Assigner Command rule 40 8.5.22 Definition: Synonym 40 8.5.23 Definition: Unfolded form of a possibly multiple declaration 40 8.5.24 Validity: Feature Declaration rule 41 8.5.25 Validity: Alias Validity rule 42 8.6 The inheritance relation 43 8.6.1 Syntax : Inheritance parts 43 8.6.2 Definition: Parent part for a type, for a class 43 8.6.3 Definition: Multiple, single inheritance 43 - iii - 8.6.4 Validity: Class ANY rule 44 8.6.5 Validity: Universal Conformance principle 44 8.6.6 Definition: Unfolded Inheritance Part of a class 44 8.6.7 Definition: Inherit, heir, parent 45 8.6.8 Definition: Conforming, non-conforming parent 45 8.6.9 Definition: Ancestor types of a type, of a class 45 8.6.10 Definition: Ancestor, descendant 45 8.6.11 Definition: Proper ancestor, proper descendant 45 8.6.12 Validity: Parent rule 45 8.6.13 Syntax : Rename clauses 46 8.6.14 Validity: Rename Clause rule 46 8.6.15 Semantics: Renaming principle 47 8.6.16 Definition: Final name, extended final name, final name set 47 8.6.17 Definition: Inherited name 47 8.6.18 Definition: Declaration for a feature 47 8.7 Clients and exports 48 8.7.1 Definition: Client relation between classes and types 48 8.7.2 Definition: Client relation between classes 48 8.7.3 Definition: Indirect client 48 8.7.4 Definition: Supplier 48 8.7.5 Definition: Simple client 48 8.7.6 Definition: Expanded client 49 8.7.7 Definition: Generic client, generic supplier 49 8.7.8 Definition: Client set of a Clients part 49 8.7.9 Syntax