Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/answers/eiffel-faq

Text File | 1993-12-23 | 46KB | 1,101 lines

Newsgroups: comp.lang.eiffel,comp.answers,news.answers
From: [e-mail] (Roger Browne)
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nic.hookup.net!europa.eng.gtefsd.com!uunet!pipex!uknet!demon!eiffel.demon.co.uk!rogerb
Subject: comp.lang.eiffel Frequently Asked Questions (FAQ)
Organization: Everything Eiffel
Reply-To: [e-mail]
X-Newsreader: Demon Internet Simple News v1.26
Lines: 1090
Followup-To: comp.lang.eiffel
Expires: +1 month
Approved: [e-mail]
Summary: Eiffel is a pure object-oriented language designed to promote
         software correctness and re-use.
Date: Thu, 23 Dec 1993 15:29:29 +0000
Message-ID: <[e-mail]>
Sender: [e-mail]
Xref: senator-bedfellow.mit.edu comp.lang.eiffel:4469 comp.answers:3128 news.answers:16118

Archive-name: eiffel-faq
Last-modified: 23 December 1993

EIFFEL: FREQUENTLY ASKED QUESTIONS
----------------------------------

This question-and-answer list is posted monthly to the Usenet newsgroups
comp.lang.eiffel, comp.answers and news.answers.

Please send corrections, additions and comments to Roger Browne
([e-mail]).

This information is abstracted and condensed from the posts of many
contributors to comp.lang.eiffel, supplemented by information from vendors.
No guarantees are made regarding its accuracy.

You can receive the latest copy by anonymous file transfer from:

   ftp.cm.cf.ac.uk  /pub/eiffel/eiffel-faq
   rtfm.mit.edu     pub/usenet/news.answers/eiffel.faq

or by sending an email message to [e-mail] with the
following message body:

   send Eiffel eiffel-faq

----------

CONTENTS

Changes since the last posting:

   Q02: Added birth date for Eiffel
   Q03: TowerEiffel now available
   Q04: Student license also available from TowerEiffel
   Q05: Shareware interpreter for a subset of Eiffel 2.3 on Atari ST
   Q09: TowerEiffel available under SunOS and Solaris
   Q16: Various address and phone number changes for suppliers
   Q17: Date for TOOLS USA '94 conference

   Thanks to Jan Sandquist and Laurent Bloch 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?
   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) Is it true that Eiffel is too slow?
   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?

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?

----------

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 a complete language definition unto itself. It 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,
particularly C. Eiffel supports the concept of "Design by Contract" to
improve software correctness.

Eiffel is also an excellent vehicle for software education, including for a
first programming course.

Eiffel is typically implemented by compilation to C, ensuring wide
portability. Eiffel compilers generally can generate stand-alone C packages
including makefiles to aid in porting finished applications.

----------

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.

----------

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.

A version of Eiffel called Eiffel/S is produced by SiG Computer GmbH of
Germany. It is based on the Eiffel 3 language definition.

Eiffel/S Version 3, release 1.21 includes:
   - command-line compiler with automatic configuration management
   - libraries
   - manual
   - book "Eiffel: The Language" by Dr Meyer.

Tower Technology Corporation of Austin, TX produce TowerEiffel. It
includes:
   - compiler
   - many programming tools
   - an emacs-based integrated programming environment
   - Eiffel 3 kernel and support libraries

In addition, there are at least three other Eiffel compiler development
projects underway. One may release a commercial version of Eiffel 3 in the
very near future. Availability of high value Eiffel implementations will
soon be excellent.

There is also work going on to create business application development
environments based on Eiffel, Eiffel CASE-style tools, an Eiffel-based
OODB. Soon the most telling need will be for more high quality commercial
Eiffel libraries.

----------

Q04)   Are their 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.

ISE is also selling student licenses on their lower cost platforms.

TowerEiffel offers a much reduced price for a student license.

----------

Q05)   Is Eiffel available in the public domain?

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.

The following Eiffel archive sites allow anonymous file transfer:

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

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 ([e-mail]).

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
   ([e-mail]).

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
powerful constructs of its own such as iteration abstraction, built-in
arrays, overloading, object constants and programmer specified dynamic
dispatching.

Sather is available for free, under a very unrestrictive license. The
documentation for Sather, and the ICSI implementation of it, are available
by anonymous file transfer from the following sites:

   ftp.ICSI.Berkeley.edu   /pub/sather
   ftp.gmd.de              /pub/Sather
   sra.co.jp               /pub/lang/sather
   lynx.csis.dit.csiro.au  /pub/sather

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 minor 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 new 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.

----------

Q08)   Are any magazines or newsletters available concerning Eiffel?

Eiffel Outlook is a bi-monthly newsletter devoted to Eiffel and Sather. It
is 24 pages long and focuses mainly on practical and technical issues
involved in using these languages. Contact Tower Technology Corporation for
more information. 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
   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 for customers of SiG Computer, the
makers of Eiffel/S. Contact SiG Computer for more information.

The Eiffel Interest Group of the UK and Ireland also 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 four
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.21 is available for DOS on the PC. As at June 1993, the
following C compilers are supported: Microsoft C 7.0, Borland C++ 3.1, Gnu
2.2.2 (with DJ Expander), Gnu 2.2.2 (with 0.8e EMX expander), Zortech 3.0,
Watcom 9.0A (not 9.0) and 9.5 Beta. SIG uses Zortech 3.0 in-house. It works
best with a 32-bit compiler, e.g. Gnu, Zortech, Watcom.

Eiffel/S 1.21 is also available for OS/2 on the PC, and for the following
Unix systems: PC Unix (Interactive, SCO, and ESIX), Sun SPARC, NeXT,
HP/9000, DEC 5xxx, Sony News and RS/6000.

ISE's Eiffel 3 is available for IBM RISC 6000, Sparc (SunOS 4.1.X), Silicon
Graphics, Fujitsu, Data General Avion, HP/UX, and SCO Open Desktop. It is
expected within the next few weeks for Pyramid and other 88open-conformant
platforms, and MIPS. Development is said to be well-advanced for NeXTSTEP,
VMS, AIX (PS/2), Apple A/UX, Solaris 2 and several other Unix platforms.

Tower Corporation's TowerEiffel is available on Sun SPARC or compatible
running SunOS 4.1.2 or 4.1.3, with gcc 2.2.2, gcc 2.4.5 or Sun's acc 2.0.1
C compiler; also running Solaris 2.1 with gcc 2.4.5

Future ports of TowerEiffel are planned for AIX, IRIX, HPUX, DG/UX,
NextStep, Windows NT, OS/2, VMS and various Intel-based Unix systems.

----------

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.

>From IP (either inside DEC or outside DEC):
   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 neighbor 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.

----------

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

A lot. For ISE Eiffel, 10 MB just to install the basic tools and library
source. Once you start compiling those libraries it will be 20-25 MB. I'd
recommend 40 MB for a minimum development environment.

To install Eiffel/S, you need about 5MB disk space. To run it you need at
least 4MB RAM, and at least 10MB available disk space, but a heavy user
would want twice that 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 and current Eiffel
implementations are not that hot at optimizing for space or time.
Interestingly, as applications grow Eiffel applications seem to grow less
rapidly as new capabilities are added. Reuse does help out tremendously in
this regard. A good Eiffel compiler should eventually allow 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 Dr.
Meyer's latest book, "Eiffel: The Language", as the initial definition of
the language.

The NICE board of directors consists of Bertrand Meyer, Darcy Harrison,
Frieder Monninger, Peter Williams and Rock Howard (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
[e-mail]

NICE (Nonprofit International Consortium for Eiffel)
2701 Stratford Drive
Austin, TX 78746
TEL: [phone]
FAX: [phone]
email: [e-mail]

----------

Q14)   Is it true that Eiffel is too slow?

Early versions of Eiffel were slow, and the generated code was bulky.
Recent implementations have improved dramatically. However, to achieve
maximum performance under any Eiffel implementation, run-time assertion
monitoring must be disabled.

In theory, there is nothing about Eiffel that should cause Eiffel
applications to be larger or slower than C++. Future Eiffel compilers can
be expected to further improve run time efficiency.

----------

Q15)   Are there any Eiffel user groups?

International Eiffel                    UK and Ireland Eiffel Interest
  User Group (IEUG)                       Group
Darcy Harrison                          Caroline Browne
Attention: IEUG                         Applied Logic Developments
ISE Inc.                                9 Princeton Court
270 Storke Road, Suite 7                55 Felsham Road
Goleta, CA 93117, USA                   London SW15 1AZ
TEL [phone]                      TEL [phone]
FAX [phone]                      FAX [phone]
email [e-mail]

The UK and Ireland Eiffel Interest Group (EIG) has a quarterly meeting,
usually with a technical topic and guest speaker, and publishes a quarterly
newsletter.

----------

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 [phone]                        Canada H9S 4H4
FAX [phone]                        TEL [phone]
                                        FAX [phone]

SiG Computer GmbH                       Tower Technology Corporation
zu den Bettern 4                        1501 Koenig Lane
D 35619 Braunfels                       Austin, TX 78756 USA
Germany                                 TEL [phone]
TEL [phone]                       FAX [phone]
FAX [phone]                       email: [e-mail]
email [e-mail]

Class Technology Pty. Ltd.              Ease Pty. Ltd.
6 Pound Road                            4 Edinburgh Avenue
Hornsby NSW 2077                        Carlingford NSW 2118
Australia                               Australia
TEL [phone]                      TEL [phone]
FAX [phone]                      FAX [phone]
email [e-mail]

Everything Eiffel                       Applied Logic Group
6 Bambers Walk                          9 Princeton Court
Wesham PR4 3DG                          55 Felsham Road
England                                 London SW15 1AZ
TEL [phone]                      England
email [e-mail]         TEL [phone]
                                        FAX [phone]

EtnoTeam                                SOL
Via Adelaide Bono Cairoli 34            104 rue Castagnary
20217 Milano                            75015 Paris
Italy                                   France
TEL [phone]                        TEL [phone]
FAX [phone]                      FAX [phone]

Unirel                                  Sritech Information Technology
Centro Comerciale Osmanoro              744/51 2nd Floor
Via Volturno, 12                        10 Mian Road, 4th Block
50019 Sesto Fiorentino (FL)             Jayanagar, Bangalore
Italy                                   India 560011
TEL [phone]                       TEL [phone]
FAX [phone]                       FAX [phone]

Cromasoft                               Objective Methods Ltd
Mazatlan 101                            PO Box 17356
Col Condesa                             77 Chamberlain Rd
06140 Mexico                            Karori, Wellington
TEL [phone]                     New Zealand
FAX [phone]                     TEL [phone]
                                        FAX [phone] or 8772
                                        email [e-mail]

Seinca                                  Enea Data
C/Jorge Juan, 19 - #4                   Box 232
28001 Madrid                            Nytorpsvagen 5
Spain                                   S-183 23 Taby
TEL [phone]                     Sweden
FAX [phone]                     TEL [phone]
                                        FAX [phone]
                                        email [e-mail]

Cybertech                               Forefront Computer Services
Systens Integration for CIM               Pty. Ltd.
Suarez 1281, Third Floor,Apt.A          115 Seaford Road
CP-1288 Buenos Aires                    Seaford, Victoria 3198
Argentina                               Australia
TEL [phone]                       TEL [phone]
FAX [phone] or [phone]    FAX [phone]

Science Data Systems                    Software Research Associates
Sarphatistraat, 133                     1-1-1 Hirakawo-Cho
1018 GC Amsterdam                       Chiyoda-ku Tokyo 102
The Netherlands                         Japan
FAX [phone]                      TEL [phone]
                                        FAX [phone]

Information and Mathematical Science    Simon Parker
  Laboratory, Inc.                      45 Hazelwood
2-43-1, Ikebukuro, Toshima-ku           Shankill
Tokyo 171, Japan                        Co Dublin
email [e-mail]         Ireland
TEL [phone]                     TEL [phone]
FAX [phone]                     email [e-mail]

Objectif Concept                        SOOPS
Passage Cour-Robert 5                   Sarphatistraat 133
CH 1700 Fribourg                        NL-1018 GC Amsterdam
Switzerland                             The Netherlands
TEL [phone]                      TEL [phone]
FAX [phone]

----------

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.

Mar 7 - 11, 1994
   TOOLS EUROPE '94, Versailles, France

Mar 10 - 11, 1994
   "Eiffel In Action" (part of TOOLS conference)

Aug 1 - 5, 1994
   TOOLS USA '94, Santa Barbara, California
   Deadline for papers: 18 March

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 [phone], FAX [phone]
email [e-mail]

----------

Q18)   Why do Eiffel implementations compile to C?

(Although current Eiffel implementations compile to C, native code
compilers may become available in the future.)

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.

----------

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.

----------

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 [e-mail])

SIG Eiffel/S:

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

   The special classes, some of which are treated specially by the compiler
   -- COMPARABLE, NUMERIC, HASHABLE, BOOLEAN, CHARACTER, INTEGER, REAL,
   DOUBLE, ARRAY, BITS n, 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.)

----------

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).

[Eiffel and Sather users are welcome to make suggestions to improve this
section. This is one of the most frequently asked questions, and one of the
most confusing to newcomers. I would like to make this section simpler and
more clear.]

----------

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).

----------
-- Roger Browne, 6 Bambers Walk, Wesham PR4 3DG, UK.    |  Ph 0772-687525
-- Everything Eiffel: compilers/libraries/publications  |  [phone]


--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK   | Ph 0772-687525
-- Everything Eiffel: compilers/libraries/publications | [phone]