Newsgroups: comp.lang.eiffel,comp.answers,news.answers
From: rogerb@eiffel.demon.co.uk (Roger Browne)
Subject: comp.lang.eiffel Frequently Asked Questions (FAQ)
Organization: Everything Eiffel
Reply-To: rogerb@eiffel.demon.co.uk
Date: Fri, 9 Sep 1994 21:18:42 +0000
Message-ID: <779145522snz@eiffel.demon.co.uk>
following message body:
following message body:

   send Eiffel eiffel-faq

----------

CONTENTS

Changes since the last posting:

   Q06: Sather: mentioned lack of Design by Contract
   Q09: ISE Eiffel 3 now on NeXT, Eiffel/S available on DEC Alpha OSF/1
   L11: How can I call the parent-class version of a redefined routine?
          (new question)

   Thanks to Darcy Harrison, Frieder Monninger and Jean-Marc Jezequel and
   Adam Beneschan for their input.

Frequently Asked Questions:

   Q01) What is Eiffel?
   Q02) Where did Eiffel come from?
   Q03) What Eiffel products are available?
   Q04) Are there any school or student discounts?
   Q05) Is Eiffel available in the public domain or as shareware?
   Q06) What is Sather? How does it compare to Eiffel?
   Q07) What books are available for learning about Eiffel?
   Q08) Are any magazines or newsletters available concerning Eiffel?
   Q09) Is Eiffel available on PC, Mac, NeXT, Amiga, Atari, ...?
   Q10) Is there an archive of the comp.lang.eiffel newsgroup?
   Q11) How much memory and disk space does Eiffel development require?
   Q12) How large are typical Eiffel executables?
   Q13) Are there standards for the Eiffel language?
   Q14) How fast do Eiffel applications run?
   Q15) Are there any Eiffel user groups?
   Q16) Where can I get Eiffel products and services?
   Q17) Are there any conferences for Eiffel users?
   Q18) Why do Eiffel implementations compile to C?
   Q19) What is BON?
   Q20) Where can I get an Eiffel editor or emacs-mode?
   Q21) Where can I find Eiffel on the World-Wide-Web?

Language Issues:

   L01) What features does Eiffel have?
   L02) What changes have been made to the Eiffel language definition?
   L03) What libraries come with Eiffel?
   L04) What's the big deal about preconditions and postconditions?
   L05) Please explain and discuss covariance vs. contravariance.
   L06) Is it true that there are "holes" in the Eiffel type system?
   L07) Is there support for concurrency in Eiffel?
   L08) Why doesn't Eiffel allow function overloading?
   L09) Why are there no procedural types in Eiffel?
   L10) Why are there no class attributes in Eiffel?
   L11) How can I call the parent-class version of a redefined routine?

----------

Q01)   What is Eiffel?

Eiffel is an advanced object-oriented programming language that emphasizes 
the design and construction of high-quality and reusable software.

Eiffel is not a superset or extension of any other language. Eiffel 
strongly encourages object-oriented programming and does not allow 
dangerous practices from previous generation languages although it does 
interface to other languages such as C and C++. Eiffel supports the concept 
of "Design by Contract" to improve software correctness.

Beyond the language aspect Eiffel may be viewed as a method of software 
construction. Eiffel is an excellent vehicle for software education, 
including for a first programming course.

----------

Q02)   Where did Eiffel come from?

Eiffel was created by Bertrand Meyer and developed by his company, 
Interactive Software Engineering (ISE) of Goleta, CA.

Dr. Meyer borrowed on his extensive experience with OOP, particularly with 
Simula. He also added in important concepts from his academic work on 
software verification and computer language definition.

Eiffel's design addresses many practical concerns that software engineers 
face when creating complex software. Eiffel has evolved continually since 
its conception on September 14, 1985 and its first introduction in 1986.

Eiffel is named after Gustave Eiffel, the engineer who designed the Eiffel 
Tower.

----------

Q03)   What Eiffel products are available?

ISE Eiffel 3 is a commercially supported product available from Interactive 
Software Engineering.

ISE Eiffel 3 is a complete graphical development environment meant for the 
production of quality software, with particular attention being given to 
the development of large systems. The environment itself is written in 
Eiffel, and is an example of non-trivial system - about 3000 classes.

Eiffel/S is produced by SIG Computer GmbH of Germany. It is based on the 
Eiffel 3 language definition.

Eiffel/S release 1.3 includes:
   - command-line compiler with automatic configuration management
   - libraries
   - manual

TowerEiffel is an open high-performance Eiffel system from Tower Technology 
Corporation of Austin, Texas which includes:
   - an open-ended emacs-based development environment including syntax-
     directed highlighting, browsing options and automatic documentation
     generation in ASCII, LaTex, RTF or FrameMaker mif format.
   - an Eiffel 3 compiler that generates executables that rival C and C++
     in performance
   - the ability to directly interoperate with and generate code in C, C++
     or Objective C.
   - a multi-language source level debugger.
   - kernel and support libraries including simple persistence and
     heterogenous object distribution.

----------

Q04)   Are there any school or student discounts?

Both ISE Eiffel and SIG Eiffel/S include aggressive site-licensing and 
discount licenses for schools and universities.

Eiffel/S offers an inexpensive student or trial license. This license is 
limited to building systems with up to 75 classes. You do not have to be a 
student to buy it, and you get a discount if you subsequently upgrade to 
the full version.

TowerEiffel is available in a form identical to the commercial version of 
the product but with discounts of around 90% for professors, 80% for 
students and 70% for non-commercial licensees.

ISE offers a much-reduced price on its Linux product for individuals.

----------

Q05)   Is Eiffel available in the public domain or as shareware?

There is not currently a public domain Eiffel compiler. ISE has expressed 
willingness to support the serious efforts of those who wish to create a PD 
Eiffel, but so far no such effort has succeeded.

There is, however, a somewhat limited Eiffel 2.3 interpreter for the Atari 
ST which is shareware (DM50). The documentation is in German, and the 
example files seem quite interesting. Inheritance does not seem to be 
supported (!), but there is an interesting extension to allow "for all" and 
"for some" in assertions.

A shareware compiler for MS-DOS is likely to become available this year 
from EON software.

The following Eiffel archive sites allow anonymous file transfer:

ftp.tu-clausthal.de
pub/atari/languages/eiffel/vici_102.lzh
   The Atari ST interpreter referred to above.

ftp.cm.cf.ac.uk
/pub/eiffel
   University of Wales. Contains the latest version of this FAQ, plus the 
   front-end parser (ep) and various public domain classes. To contribute, 
   contact Ted Lawson (ted@cm.cf.ac.uk).

ftp.fu-berlin.de
/pub/heron/ep.tar.Z
   There is an Eiffel front-end parser (HERON) in the public domain, 
   created by Burghardt Groeber and Olaf Langmack of the Freie Universitat 
   in Berlin. Olaf has announced that the Freie Universitat has agreed to 
   join the NICE consortium and keep the front-end parser in sync with the 
   Eiffel language definition as it evolves.

ftp.informatik.uni-stuttgart.de
/pub/eiffel
   Falkultaet Informatik der Universitaet Stuttgart, Germany. Contains a 
   compiler generator, several encapsulations, a pretty-printer for 
   Eiffel/S, and some utility classes. To contribute, contact Joerg Schulz 
   (schulz@adam.informatik.uni-stuttgart.de).

utarlg.uta.edu
CSE/EIFFEL
   UT-Arlington, USA. Contains some code from Eiffel Outlook back issues.

wuarchive.wustl.edu
/graphics/gif/e/eiffel_tower
   Contains a GIF graphic of the eiffel tower
   (also on plaza.aarnet.edu.au from Australia only).

----------

Q06)   What is Sather? How does it compare to Eiffel?

Sather is an object-oriented language, originally patterned after Eiffel, 
created by Stephen Omohundro and others at ICSI of Berkeley, CA.

Sather simplifies some Eiffel constructs, eliminates others, and adds some 
constructs of its own such as iteration abstraction, built-in arrays, 
overloading and object constants. Sather does not support Design by 
Contract.

See the usenet newsgroup comp.lang.sather for more details.

----------

Q07)   What books are available for learning about Eiffel?

The classic text for learning about Eiffel (as well as Object-Oriented 
programming in general) is Dr. Meyer's "Object Oriented Software 
Construction". Although the language has evolved significantly since the 
book's date of publication, the presentation of the basic problems and 
solutions which motivate the object-oriented mind set are still quite 
compelling. This is the book to get if you are new to the object-oriented 
world as well as to Eiffel. (Prentice Hall, ISBN 13-629031-0)

Also by Dr. Meyer, "Eiffel: The Language", combines an introduction to 
Eiffel, the language reference, and a good deal of philosophy into its 600 
pages. This is the state of the art in OO thinking, but is a rigorous and 
comprehensive book which some readers may find heavy going despite Dr. 
Meyer's clarity of expression. It is, however, the definitive language 
reference, and essential reading for all serious Eiffel users. This book is 
now in its second _printing_ (same ISBN), with some corrections and 
clarifications (this is not a second _edition_, and none is currently 
underway). (Prentice Hall, ISBN 13-247925-7)

Dr. Meyer and Jean-Marc Nerson have edited a book about Eiffel called 
"Object-Oriented Applications". It includes an introduction to Eiffel 
technology followed by seven in-depth descriptions of large applications 
written in Eiffel. (Prentice Hall, ISBN 13-013798-7)

Robert Switzer, from Gottingen University in Germany, has written "Eiffel: 
An Introduction". This is a very clear and concise primer for those wishing 
to learn Eiffel, with many code fragments, and two substantial Eiffel 
applications. (Prentice Hall, ISBN 13-105909-2)

ISE distributes a set of 6 video lectures (about one hour each) entitled 
"Object-Oriented Software Construction", taught by Bertrand Meyer. These 
provide an overall introduction to the method and use ISE Eiffel 3 to 
illustrate the concepts.

Frieder Monninger's book "Eiffel: Objektorientiertes Programmieren in der 
Praxis" is a very down-to-earth Eiffel handbook in German. (Heise, ISBN 3-
88229-028-5).

Bertrand Meyer's "Reusable Software: The Base Object-Oriented Component 
Libraries" (Prentice Hall, ISBN 0-13-245499-8, about 530 pages) describes 
principles of library design and the taxonomy of fundamental computing 
structures that led to ISE's EiffelBase libraries. Also serves as a manual 
for the EiffelBase libraries.

Bertrand Meyer's "An Object-Oriented Environment: Principles and 
Application" (Prentice Hall, ISBN 0-13-245507-2, 240 pages) describes the 
environment and interface principles that led to the ISE Eiffel 3 
environment as well as the compilation technology (Melting Ice) that it 
uses. Also describes the EiffelBuild Graphical User Interface (GUI) 
application builder.

----------

Q08)   Are any magazines or newsletters available concerning Eiffel?

Eiffel Outlook is a bi-monthly newsletter devoted to Eiffel, now completing 
its third year of publication, Eiffel Outlook is 24 pages long and focuses 
mainly on practical and technical issues involved in using Eiffel. Trial 
subscriptions and back issues are available.

Eiffel Outlook is distributed by:

   Jay-Kell in Canada
   SIG Computer in Germany
   Everything Eiffel in the United Kingdom and France
   Simon Parker in Ireland
   IMSL in Japan
   Enea Data in Sweden
   Class Technology in Australia
   Tower Technology in the USA and for all other countries

Eiffel Post is a four page newsletter (in German) for customers of SIG 
Computer, the makers of Eiffel/S.

The Eiffel Interest Group of the UK and Ireland publishes an excellent 
newsletter for its members.

NICE has produced a four-page glossy flyer "Eiffel Success Stories", 
intended to be the first of a series.

ISE produces an 8-page newsletter "Eiffel World" which will appear several 
times a year.

----------

Q09)   Is Eiffel available on PC, Mac, NeXT, Amiga, Atari, ...?

This is the latest information that I have, but it does change rapidly.

SIG Eiffel/S 1.3 is available for DOS on the PC. As at January 1994, the 
following C compilers are supported: Microsoft C 7.0, Borland C++ 3.x, Gnu 
2.2.2 (with DJ Expander), Gnu 2.4.5 (with emx-g expander), Symantec C++ 
6.0, Watcom 9.5. SIG uses Symantec in-house. It works best with a 32-bit 
compiler, e.g. Gnu, Symantec, Watcom.

Eiffel/S 1.3 is also available for OS/2 (using GCC 2.4.5 emx-g, Watcom C 
9.5 or IBM C/Set) and Windows/NT (Microsoft 32-bit C, Watcom C 9.5 or 
Symantec C++ 6.0), and for the following Unix systems: Linux, PC Unix 
(Interactive, SCO, and ESIX), SPARC, NeXT, NeXTstep-Intel, HP/9000, DEC 
5xxx, Sony News, DG Aviion, DEC Alpha (OSF-1), and RS/6000.

ISE's Eiffel 3 (Release 3.2) is available for DEC Alpha (OSF-1), DEC MIPS 
(Ultrix), DG Aviion (and hence other 88Open platforms), Fujitsu, HP UX, IBM 
RS/6000, Linux (with Motif only), NeXTSTEP (Intel and Motorola), Pyramid, 
SCO (Open Desktop), Silicon Graphics, AIX/PS2 and Sparc (Solaris 2.3 or 
SunOS). The VMS and version is nearing completion. Development is underway 
for other platforms.

ISE Personal Eiffel is a low-cost menu/keyboard-driven implementation of 
Eiffel 3 which runs under Microsoft Windows 3.1. It does not require a C-
compiler back-end, and combines interpreted user code with precompiled 
libraries. It includes the EiffelBase, EiffelLex and EiffelParse libraries 
in source code form. You cannot use it to develop GUI software or call 
external C routines. ISE Professional Eiffel is a similar non-GUI product 
which can also generate C-code for compilation by Watcom C++ 10, and which 
makes it possible to call external C routines. ISE is developing further 
Windows products.

Tower Technology Corporation's TowerEiffel 1.3 is available and sold 
seperately for SUN Sparc or compatible running SunOS 4.1.x, SUN Sparc or 
compatible running Solaris 2.x, Solaris x86, OS/2 (non-commercial form only 
at this time), NeXTStep x86 and NeXTStep M68K.

Ports of TowerEiffel are underway for Win32 and are also planned for a 
variety of UNIX and DEC platforms.

----------

Q10)   Is there an archive of the comp.lang.eiffel newsgroup?

An archive of the newsgroup is available on gatekeeper.dec.com. The DEC 
Western Research Lab hosts it. This archive does not contain articles after 
September 1992.

The files are in /pub/plan/eiffel/usenet/USENET-xx-yyy, where `xx' 
represents the last two digits of the year and `yyy' the month of posting, 
e.g., /pub/plan/eiffel/usenet/USENET-91-AUG. Compressed versions of the 
files are also available.

>By anonymous FTP to gatekeeper.dec.com (16.1.0.2)
   cd pub/plan/eiffel/usenet
   get USENET-xx-yyy
   (or to get the compressed copy, bin, get USENET-xx-yyy.Z)

>From a UUCP neighbour of decwrl:
   "uucp decwrl!~/pub/plan/eiffel/usenet/USENET-xx-yyy.Z"

>From the DEC Easynet:
   DECWRL::"/pub/plan/eiffel/usenet/USENET-xx-yyy"

USENET-88-DEC and USENET-88-DEC.Z are the oldest entries in the archives.

There is also an archive of comp.lang.eiffel at wuarchive.wustl.edu (login 
as anonymous, send e-mail address as password). The files are in 
/usenet/comp.lang.eiffel and subdirectories. Each message is in a separate 
file, so it's not as convenient as the DEC archive, but it's more up-to-
date.

An archive of comp.lang.eiffel is available via the world-wide-web on the 
University of Wales College of Cardiff's server at 
<http://www.cm.cf.ac.uk/CLE/>

----------

Q11)   How much memory and disk space does Eiffel development require?

To install and run Eiffel/S 1.3 under DOS, you need 10MB of disk space and 
at least 4MB RAM (8MB recommended). Other products and platforms require 
more.

However, for serious Eiffel work you could easily use 100MB or more.

----------

Q12)   How large are typical Eiffel executables?

(How large are typical C executables?)

Seriously, Eiffel does impose a minimum size which is large since even 
trivial Eiffel applications bring in a lot of classes. So, a simple program 
like "Hello World" will create a relatively large executable.

Interestingly, Eiffel applications seem to grow less rapidly as new 
capabilities are added. Reuse does help out tremendously in this regard. A 
good Eiffel compiler allows large applications to be smaller than equally 
functional applications written in C.

Note that leaving assertion checking in the code increases the size of 
applications a lot. Despite this, many of us prefer that they remain 
throughout development. Some even deliver a PRECONDITIONS-only version of 
their applications to their early customers.

----------

Q13)   Are there standards for the Eiffel language?

The definition of the Eiffel language is in the public domain. This 
definition is controlled by NICE, the Non-profit International Consortium 
for Eiffel. This means that anyone or any company may create a compiler, 
interpreter, or whatever having to do with Eiffel. NICE reserves the right 
to validate that any such tool conforms to the current definition of the 
Eiffel language before it can be distributed with the Eiffel trademark. 
(i.e. advertised as an "Eiffel" compiler.)

The Eiffel trademark is owned and controlled by NICE. NICE is using 
Bertrand Meyer's book, "Eiffel: The Language" (2nd Printing), as the 
initial definition of the language.

The NICE board of directors for 1994 consists of Bertrand Meyer, Simon 
Parker and Roger Browne (chairman).

NICE has formed the Eiffel Standards Group (ESG) to resolve standards 
questions and control the evolution of the language. The three current 
Eiffel Compiler Vendors (ISE, SIG and Tower) are represented in the ESG as 
well as many important and influential users of Eiffel.

There are three committees -- Language, Library, and Future Directions.

The Language Committee will address the ambiguities in the Eiffel Version 3 
language specification as well as the differences that appear between the 
current Eiffel 3 implementations.

The Library Committee will standardize the Kernel library, then consider 
interface standards for the data structures cluster and other key Eiffel 
clusters.

The Future Requirements Committee will prioritize the long range direction 
of the standards work performed by the other two committees.

The NICE Interoperability Program (NIP) tracks the reporting and resolution 
of interoperability problems. If you are aware of a problem whereby correct 
Eiffel code will not run under a particular implementation, or where 
correct Eiffel code produces different results under different 
implementations, you are invited to report this by email to 
nice-nip@atlanta.twr.com

NICE (Nonprofit International Consortium for Eiffel)
45 Hazelwood
Shankill
Co Dublin
Republic of Ireland
TEL: +353 1 282 3487
email: nice@twr.com

----------

Q14)   How fast do Eiffel applications run?

Early versions of Eiffel were slow. Recent implementations have improved 
dramatically. However, to achieve maximum performance under any Eiffel 
implementation, run-time assertion monitoring must be switched off.

It's hard to generalise, but compared to C++, simple computation-intensive 
applications will run perhaps 15% slower. Large applications are often 
dominated by memory management rather than computation. ISE recently 
demonstrated that by simply adding a call to the garbage collector's "full-
collect" routine at a time when there were known to be few live objects, 
performance became dramatically faster than a corresponding C++ version.

----------

Q15)   Are there any Eiffel user groups?

International Eiffel                 UK & Ireland Eiffel Interest Group
  User Group (IEUG)                  Caroline Browne
Darcy Harrison - Attention: IEUG     (new address to be notified)
ISE Inc.                             (publishes a newsletter and holds
270 Storke Road, Suite 7              a quarterly meeting and seminar)
Goleta, CA 93117, USA                
TEL (805) 685-1006                   
FAX (805) 685-6869                   
email darcyh@eiffel.com               

GUE, Groupe des Utilisateurs Eiffel (France)
Jean-Marc Nerson
104 rue Castagnary, 75015 Paris
TEL +33 1 45 32 58 80
FAX +33 1 44 32 58 81
email marc@eiffel.fr
(meets every two months or so)

----------

Q16)   Where can I get Eiffel products and services?

Interactive Software Engineering, Inc.  Jay-Kell Technologies, Inc.
270 Storke Road, Suite 7                48 Lakeshore Road, Suite #1
Goleta, CA 93117                        Pointe Claire, Quebec
TEL 805-685-1006                        Canada H9S 4H4
FAX 805-685-6869                        TEL +51 4 630 1005
email info@eiffel.com                   FAX +51 4 630 1456

SIG Computer GmbH                       Tower Technology Corporation
zu den Bettern 4                        1501 Koenig Lane
D 35619 Braunfels, Germany              Austin, TX 78756 USA
TEL +49 6472 2096, FAX +49 6472 7213    TEL 512-452-9455
email eiffel@sigcomp.de                 FAX 512-452-1721
(cyrillic email eiffel@sigcomp.msk.su)  email: tower@twr.com

Class Technology Pty. Ltd.              Cybertech
6 Pound Road                            Systens Integration for CIM
Hornsby NSW 2077, Australia             Suarez 1281, Third Floor,Apt.A
TEL +61 2 477 6188                      CP-1288 Buenos Aires, Argentina
FAX +61 2 476 4378                      TEL +54 1 28 1950
email class@peg.pegasus.oz.au           FAX +54 1 322 1071 or 963 0070

Everything Eiffel                       Simon Parker
6 Bambers Walk                          45 Hazelwood
Wesham PR4 3DG                          Shankill
England                                 Co Dublin, Ireland
TEL +44 772 687525                      TEL +353 1 282 3487
email rogerb@eiffel.demon.co.uk         email sparker@eiffel.ie

EtnoTeam                                SOL
Via Adelaide Bono Cairoli 34            104 rue Castagnary
20217 Milano                            75015 Paris
Italy                                   France
TEL +39 2 261621                        TEL +33 1 45 32 58 80
FAX +39 2 26110755                      FAX +33 1 44 32 58 81

Enea Data                               Sritech Information Technology
Box 232, Nytorpsvagen 5                 744/51 2nd Floor
S-183 23 Taby, Sweden                   10 Mian Road, 4th Block
TEL +46 8 792 25 00                     Jayanagar, Bangalore, India 560011
FAX +46 8 768 43 88                     TEL +91 812 640661
email eiffel@enea.se                    FAX +91 812 643608

Cromasoft, SA de CV                     Objective Methods Ltd
Mazatlan 161                            PO Box 17356 (77 Chamberlain Rd)
Col Condesa, 06140 Mexico               Karori, Wellington, New Zealand
TEL +52 5 286 82 13                     TEL +64 4 476 9499
FAX +52 5 286 80 57                     FAX +64 4 476 9237 or 8772
email claudio@croma.sunmexico.sun.com   email dkenny@swell.actrix.gen.nz

SOOPS                                   Software Research Associates
Sarphatistraat 133                      1-1-1 Hirakawo-Cho
NL-1018 GC Amsterdam, The Netherlands   Chiyoda-ku Tokyo 102, Japan
TEL +31 20 525 6644                     TEL +81 3 3234 8789
FAX +31 20 624 6392                     FAX +81 3 3262 9719
email A731CISK@HASARA11.BITNET          email sugita@sra.co.jp

Objectif Concept                        ZumaSoft
Passage Cour-Robert 5                   6235 Paseo Canyon Drive
CH 1700 Fribourg, Switzerland           Malibu, California 90265, USA
TEL +41 37 232977                       TEL & FAX +1 310 457-6263
FAX +41 37 464889                       email 72674.3161@compuserve.com

Information and Math Science Lab Inc.   Abstraction (Jacques Silberstein)
2-43-1, Ikebukuro, Toshima-ku           18 Faubourg de l'Hopital
Tokyo 171, Japan                        2000 Neuchatel, Switzerland
email fushimi@idas.imslab.co.jp         phone +41.38.25.04.93
TEL +81 3 3590 5211                     fax +41.38.259.857
FAX +81 3 3590 5353                     email 100015.304@compuserve.com

Eon Software                            Feinarbeit
19 Stapleton Road                       Altenbraker Strasse 4
Heddington, Oxford OX3 7LX, UK          D-12053 Berlin, Germany
TEL +44 865 741452                      TEL & FAX +49 30 6215863
email ian@eonsw.demon.co.uk

----------

Q17)   Are there any conferences for Eiffel users?

The conferences listed here are not just for Eiffel. Eiffel shares the 
spotlight with other object-oriented languages including C++ and Smalltalk.

Nov 29 - Dec 1, 1994
   TOOLS PACIFIC '94, Melbourne, Australia

Mar 6 - 9, 1995
   TOOLS EUROPE, Versailles, France
   Deadline for papers: 1 Oct

TOOLS is the major international conference devoted to the applications of 
Object-Oriented technology. Other events, such as Eiffel User Group 
meetings or NICE meetings are often held in conjunction with TOOLS.

TOOLS Conferences
PO Box 6863, Santa Barbara, CA 93160, USA
TEL (805) 685 1006, FAX (805) 685 6869
email tools@tools.com

----------

Q18)   Why do Eiffel implementations compile to C?

(Most, but not all, current Eiffel implementations compile to C or C++.)

By using C as a target language, an Eiffel implementor can:

-  bring Eiffel to the marketplace faster and at lower cost
-  port their implementation more easily to other platforms
-  take advantage of optimisation provided by the C compiler

Much of the technology that makes Eiffel relatively simple to use also 
makes it more difficult to implement (an Eiffel-to-C compiler is perhaps 4 
to 5 times more difficult to create than a native Pascal compiler).

Compiling Eiffel to C seems to work well under Unix. C is sometimes thought 
of as the native code of Unix.

On the other hand, C is not universal on other platforms, and the Eiffel 
purchaser may need to buy a C compiler as well, and possibly replace it if 
the supported C compilers change with new versions of the Eiffel compiler.

With a native-code compiler, you'd get somewhat better throughput and the 
potential for smaller executables and slightly better performance. You'd 
also get a higher price and an even longer wait for Eiffel to show up on 
other than the leading market share machines.

----------

Q19)   What is BON?

BON ("Business Object Notation") is a method for high-level analysis and 
design, offering a seamless transition to an Eiffel implementation. The 
method emphasizes Design by Contract and systematic development. For more 
information on BON, see the Communications of the ACM, September 1992.

A book that Jean-Marc Nerson co-authored with Kim Walden, entitled 
"Seamless Object-Oriented Software Architectures: Analysis and Design of 
Reliable Systems", describing the BON method in detail, will be published
by Prentice Hall during 1994.

----------

Q20)   Where can I get an Eiffel editor or emacs-mode?

Franck Arnaud's Eiffel extension to the Windows/WindowsNT programmers 
editor Codewright from Premia allows you to see Eiffel code in colour, has 
smart indenting and a few templates. Available by anonymous FTP from
ftp://ftp.cm.cf.ac.uk/pub/eiffel/tools/cweiffel.zip

The WINEDIT shareware programmer's editor offers colour syntax 
highlighting, works with Eiffel/S under MS-Windows, and is available from:
ftp://src.doc.ic.ac.uk/computing/systems/ibmpc/windows3/programr/we-30d.zip
and ftp://gatekeeper.dec.com/.f/micro/msdos/win3/programr/we-30d.zip

Alan Philips' free Programmers File Editor also works with Eiffel/S under 
MS-Windows, has templates but not syntax highlighting, available from:
ftp://src.doc.ic.ac.uk/computing/systems/ibmpc/simtel/windows3/pfe0506.zip
and ftp://gatekeeper.dec.com/.f/micro/msdos/win3/programr/pfe0506.zip

Tower Technology Corporation supplies an Eiffel 3 emacs mode that supports 
syntax-directed highlighting, auto-indentation and is easily customized for 
font use, color and indentation amounts. It comes as part of the 
TowerEiffel system, but is also available free for anyone who requests it. 
Send email to elisp@atlanta.twr.com to get the latest version.

----------

Q21)   Where can I find Eiffel on the World-Wide-Web?

An Eiffel home page is held on the University of Wales College of Cardiff's 
server at <http://www.cm.cf.ac.uk/CLE/>

----------

L01)   What features does Eiffel have?

Eiffel is a pure object-oriented language. Its modularity is based on 
classes. It stresses reliability, and facilitates design by contract. It 
brings design and programming closer together. It encourages the re-use of 
software components.

Eiffel offers classes, multiple inheritance, polymorphism, static typing 
and dynamic binding, genericity (constrained and unconstrained), a 
disciplined exception mechanism, systematic use of assertions to promote 
programming by contract, and deferred classes for high-level design and 
analysis.

Eiffel has an elegant design and programming style, and is easy to learn.

----------

L02)   What changes have been made to the Eiffel language definition?

Eiffel is still a relatively new language, and there have been a number of 
changes to its definition. Here is a summary of the major changes:

1. Changes between the publication of "Object-Oriented Software 
   Construction" in 1988, and the release of Eiffel 2.3:

   - Constrained genericity enables a generic class to restrict its
     generic parameters to the descendants of a given class

   - The indexing clause allows information about a class to be
     recorded for extraction by archival, browsing and query tools

   - The assignment attempt operator "?=" provides a way to make
     type-safe assignments going against the inheritance hierarchy

   - User-defined infix and prefix operator features

   - Expanded types support composite objects without dynamic
     allocation, and with value semantics

   - The obsolete clause for smooth library evolution

   - The unique keyword for implicitly-assigned integer codes

   - The multi-branch instruction (similar to a case statement)

   - The boolean operator for implication ("implies")

2. Changes with the introduction of Eiffel Version 3:

   - The feature adaptation subclause must now be terminated with "end"

   - Semicolons as instruction separators are optional

   - Groups of features are bracketed by a feature clause. All features
     are exported unless the feature clause specifies a restriction.
     The repeat subclause is no longer needed, because inherited
     features keep the original export status they had in the parent
     unless they are redefined, or are the subject of an export
     subclause in the feature adaptation clause.

   - Preconditions can only be replaced by weaker ones, postconditions
     can only be replaced by stronger ones. This is now enforced by the
     language through the use of "require else" in preconditions and
     "ensure then" in postconditions.

   - Ambiguities in repeated inheritance are resolved by a select
     clause.

   - A feature can no longer be replicated and redefined in the same
     feature adaptation clause, however the same effect can be achieved
     through repeated inheritance

   - Two or more features may be defined at the same time (e.g. "f1, f2
     is...").

   - The keyword "frozen" before a feature name prohibits redefinition
     of the feature in descendants

   - In an anchored declaration, the anchor may now also be a formal
     argument of the enclosing routine

   - A class may have zero, one or more creation procedures, designated
     with the "creation" keyword. A new creation syntax using the "!!"
     symbol allows the appropriate creation procedure to be specified.
     It is also possible to directly create an object of any type which
     conforms to the entity to which it is being attached.

   - The meaning of dot notation has been made more uniform, and
     alternative constructs have been provided for the special
     language-defined features that previously used dot notation:
         x.Create   is now  !! x
         y.Clone(x) is now  y := clone(x)
         x.Forget   is now  x := Void
         x.Void     is now  x = Void
         x.Equal(y) is now  equal(x, y)

   - Manifest arrays can be specified, for example
         <<"Jan", "Feb", "Mar">>
     which also provides a way to pass a variable number of arguments
     to a routine.

   - The command-line parameters are made available to the creation
     procedure of the root class as an array of strings.

   - A default rescue procedure called default_rescue may be defined
     and inherited.

   - A class may be declared to be an expanded class, in which case any
     type based on that class will be expanded.

   - An object may no longer contain a reference to an expanded object
     that is a sub-object of another object. Instead, upon assignment
     of an expanded object to a non-expanded object, the expanded
     object will be cloned, and a reference to the newly-cloned object
     will be stored in the non-expanded object.

   - The operator "div" has been replaced by "//", and the operator
     "mod" has been replaced by "\\".

3. Changes between first and second printings of "Eiffel: The Language"

   - New basic types INTEGER_REF, REAL_REF, CHARACTER_REF and
     BOOLEAN_REF etc have been introduced to provide non-expanded basic
     types.

   - Introduction of the POINTER type to enable external references to
     be passed around in Eiffel programs.

   - Calls from Eiffel to external routines no longer implicitly pass
     the current object as the first parameter.

   There are many other (more minor) changes, which Neil Wilson has
   summarized in ftp.cm.cf.ac.uk:/pub/eiffel/Docs in both Microsoft Rich
   Text Format and ASCII.

----------

L03)   What libraries come with Eiffel?

ISE Eiffel 3:

EiffelBase (the basic library) is a library of reusable components covering 
data structures and algorithms. It is the result of long-going systematic 
effort at classifying the fundamental patterns and structures of computer 
science in a Linnaean manner. It relies heavily on the Eiffel method, in 
particular assertions (preconditions, postconditions, class invariants), 
Design by Contract, constrained genericity, and repeated inheritance.

EiffelVision (the GUI library) is an encapsulation of essential graphical 
abstractions. It makes it possible to build graphical Eiffel applications 
without having to learn and use the internal details of X, Motif, OpenLook 
or other window systems, as they are all encapsulated in EiffelVision's 
classes in a form that is closer to application-related concepts.

EiffelLex provides a set of lexical analysis facilities.

EiffelParse (still in a somewhat provisional state) is an object-oriented 
approach to parsing.

Other libraries are under development; in particular, third-party
products are being integrated into the EiffelShelf distribution.
(If you are interested in submitting components to the EiffelShelf,
for profit or just for fame, please contact shelf@eiffel.com)

SIG Eiffel/S:

   The universal classes -- GENERAL, PLATFORM, ANY and NONE

   The special classes, some of which are treated specially by the compiler 
   -- PART_COMPARABLE, COMPARABLE, NUMERIC, HASHABLE, BOOLEAN, CHARACTER, 
   INTEGER, REAL, DOUBLE, ARRAY, BITS n, OBJECT_STRUCTURE and STRING

   ENVIRONMENT -- provides access to command line arguments and environment 
   variables

   BASIC_IO -- access to standard input, standard output and error output 
   serial I/O

   FORMAT -- conversion of other data types to and from strings

   EXCEPTION -- fine grained access to exception handling

   SYSTEM_TIME -- system time interface

   INTERNAL -- control of the garbage collector

   The FILES cluster: FILE, FILE_SYSTEM, FSYS_DAT -- files are modelled as 
   persistent dynamic arrays

   TEXTFILE -- treats an ASCII text file as an array of strings

   The SORTER class -- a sorting 'expert' that knows how to sort arrays 
   optimally

   The MATH class -- trig, log, truncation, and a few constants

   The basic container classes -- classified according to uniqueness (can 
   the same object occur more than once in the container?), ordering (are 
   objects in the container kept in sorted order?) and search access (does 
   one search for a key, or for the object itself?), as well as by 
   efficiency (is speed or size more important?): LIST, SORTED_LIST, 
   SIMPLE_TABLE, HASH_TABLE, SORTED_TABLE, SHORT_LIST, SHORT_TABLE, 
   SHORT_SORTED_LIST and SHORT_SORTED_TABLE

   Other container classes -- associative arrays accessed by a hashable 
   key: DICTIONARY (with unique keys) and CATALOG (with multiple items per 
   key)

   Specialised container classes -- STACK, QUEUE, PRIORITY_QUEUE and 
   KEY_PRIORITY_QUEUE

   Abstract container classes -- define much of the interface of 
   containers: COLLECTION, TABLE, SORTED_COLLECTION and SORT_TABLE.

   Iterator classes -- objects stored within containers can be visited 
   sequentially with iterators. More than one iterator can be active on a 
   container at one time: TRAVERSABLE, TWOWAY_TRAVERSABLE, ITERATOR and 
   TWOWAY_ITER.

   The GRAPH Cluster -- a graph is defined by the classes VERTEX and EDGE. 
   It may have weighted edges (WT_GRAPH) or unweighted edges (GRAPH). 
   Iterators are provided to visit the edges emanating from a vertex 
   (EDGE_ITER); or all the vertices of a graph in breadth-first order 
   (BREADTH_ITER), depth-first order (DEPTH_ITER) or topological order 
   (TOP_ITER).

   The MATCHER Cluster -- the MATCHER class is a pattern matcher that can 
   build and activate an automaton to search for patterns in text. 
   Effective descendants search for text using the Rabin-Karp algorithm 
   (RK_MATCHER), the Knuth-Morris-Pratt algorithm (KMP_MATCHER) and the 
   Boyer-Moore algorithm (BM_MATCHER). Others search for Regular 
   Expressions (RE_MATCHER) and lists of keywords (KEYWORD_MATCHER). 
   TXT_MATCHER is an iterator that searches for multiple occurrences of a 
   pattern in an array of strings, using any of the matcher classes.

   The documentation is brief but readable, including examples and hints 
   for adding new containers or matchers. All in all, a smaller but 
   possibly tighter set of libraries.

(This response may give the appearance that Eiffel/S libraries are much
more extensive than ISE's, but the converse is true.)

TowerEiffel comes with kernel and support libraries. Special libraries are 
included for improving interoperability with Eiffel/S. A small subset of 
the Eiffel Booch Components (described below) are included as well as a 
Serialization library that supports simple persistence and/or heterogenous 
distribution of any Eiffel instance, no matter how deeply nested or self-
referential.

The Eiffel Booch Components are available seperately and are a joint 
product of Rational Software Inc. and Tower Technology. The Eiffel Booch 
Components are efficient and orthoginal data structure classes that come 
complete with test drivers. Included are BC_BAG, BC_COLLECTION, BC_DEQUE, 
BC_DICTIONARY, BC_GRAPH, BC_LIST, BC_MAP, BC_QUEUE, BC_RING, BC_SET, 
BC_STACK, and BC_TREE. Each of these comes in a variety of forms offering 
trade-offs in speed and memory utilization. Also included are dozens of 
classes for pattern matching, sorting, iteration and searching, as well as 
nodes, hash tables and more.

----------

L04)   What's the big deal about preconditions and postconditions?

The big deal is that it supports programming by contract. For example, 
preconditions (require clauses) are simple boolean statements that are used 
to check that the input arguments are valid and that the object is in a 
reasonable state to do the requested operation. If not, an exception is 
generated. Similarly, postconditions (ensure clauses) make sure that a 
method has successfully performed its duties, thus "fulfilling its 
contract" with the caller. Invariants are boolean expressions that are 
checked every time an object method returns back to a separate object.

You can use these ideas in any object-oriented programming language, but 
usually must supply your own assertion mechanisms or rely on programmer 
discipline. In Eiffel, the ideas are integrated into the whole fabric of 
the environment. We find them used by:

-- the exception handling mechanism.
   (Tracebacks almost always identify the correct culprit code since 
   preconditions almost always denote an error in the calling method, while 
   postconditions denote an error in the called method.)

-- the automatic compilation system.
   (Assertions can be disabled entirely or selectively by type on a per 
   class basis.)

-- the Eiffel compiler
   (Invariants, preconditions and postconditions are all inherited in a 
   manner that makes logical sense.)
   (Assertion expressions are not allowed to produce side effects so they 
   can be omitted without effect.)

-- the automatic documentation tools
   (Preconditions and postconditions are important statements about what a 
   method does, often effectively describing the "contract" between the 
   caller and callee. Invariants can yield information about legal states 
   an object can have.)

In the future we expect to see formal methods technology work its way into 
the assertion capability. This will allow progressively more powerful 
constraints to be put into place. In addition, if a conjecture by Dr. Meyer 
bears fruit, the notion of preconditions may be extended into an important 
mechanism for the development of parallel programming.

----------

L05)   Please explain and discuss covariance vs. contravariance.

Consider the following situation: we have two classes PARENT and CHILD. 
CHILD inherits from PARENT, and redefines PARENT's feature 'foo'.

   class PARENT
      feature
         foo (arg: A) is ...
   end; -- PARENT

   class CHILD
      inherit
         PARENT redefine foo
      feature
         foo (arg: B) is ...
    end; -- CHILD

The question is: what restrictions are placed on the type of argument to 
'foo', that is 'A' and 'B'? (If they are the same, there is no problem.)

Here are two possibilities:

   (1)  B must be a child of A (the covariant rule - so named because in 
        the child class the types of arguments in redefined routines are 
        children of types in the parent's routine, so the inheritance 
        "varies" for both in the same direction)

   (2)  B must be a parent of A (the contravariant rule)

Eiffel uses the covariant rule.

At first, the contravariant rule seems theoretically appealing. Recall that 
polymorphism means that an attribute can hold not only objects of its 
declared type, but also of any descendant (child) type. Dynamic binding 
means that a feature call on an attribute will trigger the corresponding 
feature call for the *actual* type of the object, which may be a descendant 
of the declared type of the attribute. With contravariance, we can assign 
an object of descendant type to an attribute, and all feature calls will 
still work because the descendant can cope with feature arguments at least 
as general as those of the ancestor. In fact, the descendant object is in 
every way also a fully-valid instance of the ancestor object: we are using 
inheritance to implement subtyping.

However, in programming real-world applications we frequently need to 
specialize related classes jointly.

Here is an example, where PLOT_3D inherits from PLOT, and DATA_SAMPLE_3D 
inherits from DATA_SAMPLE.

   class PLOT
      feature
         add(arg: DATA_SAMPLE) is ...

   class PLOT_3D
      inherit
         PLOT redefine add
      feature
         add(arg: DATA_SAMPLE_3D) is ...

This requires the covariant rule, and works well in Eiffel.

It would fail if we were to put a PLOT_3D object into a PLOT attribute and 
try to add a DATA_SAMPLE to it. It fails because we have used inheritance 
to implement code re-use rather than subtyping, but have called a feature 
of the ancestor class on an object of the descendant class as if the 
descendant object were a true subtype. It is the compiler's job to detect 
and reject this error, to avoid the possibility of a run-time type error.

Here's another example where a real-world situation suggests a covariant 
solution. Herbivores eat plants. Cows are herbivores. Grass is a plant. 
Cows eat grass but not other plants.

   class HERBIVORE                               class PLANT
   feature
      eat(food: PLANT) is ...
      diet: LIST[PLANT]

   class COW                                     class GRASS
   inherit                                       inherit
      HERBIVORE                                     PLANT
         redefine eat
      end
   feature eat(food: GRASS) is ...

This does what we want. The compiler must stop us from putting a COW object 
into a HERBIVORE attribute and trying to feed it a PLANT, but we shouldn't 
be trying to do this anyway.

Also consider the container 'diet'. We are not forced to redefine this 
feature in descendant classes, because with covariant redefinition of the 
argument to 'eat', the feature 'diet' can always contain any object that 
can be eaten (e.g. grass for a cow). (With contravariant redefinition of 
the argument to 'eat', it would be necessary to re-open the parent class to 
make the type of the container 'diet' more general).

To summarise: Real-world problems often lend themselves to covariant 
solutions. Eiffel handles these well. Incorrect programs in the presence of 
covariant argument redefinition can cause run-time type errors unless the 
compiler catches these.

Sather uses the contravariant rule, but uses separate mechanisms for 
subtyping and code reuse and only allows dynamic binding on true subtypes. 
This seems to make contravariance work well, but it can force the Sather 
programmer to use concrete types when modelling covariant problems. 
Concrete types cannot be further subtyped in Sather, so this can reduce the 
potential for re-use (in Eiffel, any type can be further subtyped, but the 
compiler must check that it is used validly).

----------

L06)   Is it true that there are "holes" in the Eiffel type system?

No. The design of Eiffel makes it possible to catch all type errors at 
compile time, so that an Eiffel program cannot abort with a run time type 
error.

However, to catch the more obscure type errors at compile time, the 
compiler must analyse the way that classes interact within the entire 
system, rather than just looking at each class one by one. This type of 
system-wide checking is also necessary for many compiler optimisations.

Because system-wide compile-time validity checking can be complex, some 
compilers insert run-time traps for these errors instead, and some may fail 
to correctly trap these errors. Ask your Eiffel compiler vendor how they 
handle these type problems.

----------

L07)   Is there support for concurrency in Eiffel?

Eiffel 3 does not support concurrency; neither do current commercial 
compilers. However, work on concurrency is one of the hottest Eiffel-
related research topics.

For four articles on concurrency facilities for Eiffel, including Bertrand 
Meyer's article "Systematic Concurrent Object-Oriented Programming", see 
the September 1993 "Communications of the ACM" (Vol. 36, Number 9).

----------

L08)   Why doesn't Eiffel allow function overloading?

In Eiffel, no two features of a class may have the same identifier, 
regardless of their respective signatures.  The prevents the use of 
function overloading ("multiple polymorphism"), a common programming 
technique in languages like C++.

Eiffel is designed to be minimal: it includes exactly the features that its 
designer considered necessary, and nothing else.

Because Eiffel already supports (single) polymorphism through its 
inheritance system, the only positive thing that function overloading buys 
you is reducing the number of feature names you have to learn. This is at 
the expense of reducing the ability of the compiler to trap mistakes (often 
type errors).

Readability is also enhanced when overloading is not possible. With 
overloading you would need to consider the type of the arguments as well as 
the type of the target before you can work out which feature is called. 
With multiple inheritance and dynamic binding this is awkward for a 
compiler and error-prone for a human. There is no intuitive rule which 
could be used to disambiguate routine calls where there is no "nearest" 
routine.

However, in Eiffel it's easy to write one routine with arguments of the 
most general applicable type, then use the assignment attempt operator to 
carry out the appropriate operation according to the run-time type of the 
arguments (thereby explicitly programming the disambiguation "rules").

Having said that, the lack of multiple polymorphism does force us to write 
some common mathematical operations (e.g. matrix math) in an awkward way, 
and forces arithmetic expressions to be treated specially (the "arithmetic 
balancing rule", ETL p385). But no-one has come up with a solution which is 
so simple, elegant and useful that it improves the quality of Eiffel as a 
whole.

----------

L09)   Why are there no procedural types in Eiffel?

The notion of allowing a routine to be passed as an argument to a routine 
is in many people's view incompatible with the O-O method. The definition 
of object-orientation implies that every operation belongs to an object 
type, so one does not manipulate routines just by themselves.

A possible technique when one feels the need to use a routine argument is 
to write a class and include the routine in it. Then (rather than passing a 
routine argument) pass an object - an instance of this class - to which the 
routine can then be applied. This is a more flexible approach in the long 
term. For example, you may later add an "undo" routine to your routine-
containing class, or an attribute such as "time of last execution".

----------

L10)   Why are there no class attributes in Eiffel?

In Eiffel, the "once" function provides greater functionality in a more 
disciplined way. The body of a "once" function is executed once only, when 
it is first called. Thereafter, the "once" function returns the same Result 
without re-executing its body.

The "once" function can therefore be used to implement a shared constant 
object (computed on its first use), or a shared attribute of reference type 
(initialized on its first use).

A "once" function can be included in a mixin class. The shared attribute 
returned by that once function is then available to all instances of those 
classes which inherit from the mixin class.

----------

L11)   How can I call the parent-class version of a redefined routine?

When an inherited routine is redefined in a child class, is there a way for 
the redefined routine to call the version in the parent class?

1) If you are responsible for the design of the parent class, you may
   anticipate such a need. You may provide multiple versions of the same
   routine body, with some versions frozen (not redefinable):

   class PARENT
   feature foo, frozen parent_foo is
      do
         ...
      end
   end

   class CHILD
   inherit
      PARENT
         redefine foo
      end
   feature foo is
      do
         parent_foo
         ...
      end
   end

2) Otherwise, you use repeated inheritance to get two versions of 'foo',
   and redefine one of them:

   class PARENT
   feature foo is
      do
         ...
      end
   end

   class CHILD
   inherit
      PARENT
         rename foo as parent_foo
      end
      PARENT
         redefine foo
         select foo  -- (in case of dynamic binding)
      end
   feature
      foo is
         do
            parent_foo
            ...
         end
   end


-- 
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK   | Ph 0772-687525
-- Everything Eiffel: compilers/libraries/publications | +44-772-687525

