Newsgroups: comp.lang.eiffel,comp.answers,news.answers From: rogerb@eiffel.demon.co.uk (Roger Browne) Path: bloom-beacon.mit.edu!hookup!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!uknet!demon!eiffel.demon.co.uk!rogerb Organization: Everything Eiffel Reply-To: rogerb@eiffel.demon.co.uk X-Newsreader: Demon Internet Simple News v1.26 Lines: 1163 Subject: comp.lang.eiffel Frequently Asked Questions (FAQ) Followup-To: comp.lang.eiffel Expires: +1 month Approved: news-answers-request@MIT.Edu Summary: Eiffel is a pure object-oriented language designed to promote software correctness and re-use. Date: Tue, 26 Apr 1994 08:21:19 +0000 Message-ID: <767348479snz@eiffel.demon.co.uk> Sender: usenet@demon.co.uk Xref: bloom-beacon.mit.edu comp.lang.eiffel:2222 comp.answers:5078 news.answers:18657 Archive-name: eiffel-faq Last-modified: 26 April 1994 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 (rogerb@eiffel.demon.co.uk). 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. This compilation is by Roger Browne. Distribution over the Internet or by electronic mail is unrestricted. Other use requires my permission. 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 archive-server@cm.cf.ac.uk with the following message body: send Eiffel eiffel-faq ---------- CONTENTS Changes since the last posting: Q03: Removed references to vapourware Q13: Changes to NICE Board Q16: Various changes to Eiffel reseller list Q20: Where can I get an Eiffel editor or emacs-mode? (new question) Thanks to Steve Tynor, Bertrand Meyer, Alan Philips, Mike Davis and Franck Arnaud 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) 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? 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? ---------- 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. Eiffel is typically implemented by compilation to C, ensuring wide portability. ---------- 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.3 includes: - command-line compiler with automatic configuration management - libraries - manual 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 ---------- 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 student, university or non- commercial licenses. ---------- 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 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 powerful constructs of its own such as iteration abstraction, built-in arrays, overloading and object constants. 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. Frieder Monninger's book "Eiffel: Objektorientiertes Programmieren in der Praxis" is a very down-to-earth Eiffel handbook for German speakers. (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. ---------- 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 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 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, Pyramid, SCO (Open Desktop), Silicon Graphics and Sparc (Solaris 2.3 or SunOS). NeXTSTEP (Intel and Motorola) is also available (for EiffelBench only, so far). The VMS version is nearing completion. Development is underway for other platforms. Tower Corporation's TowerEiffel (Release 1.2) is available on Sun SPARC or compatible running SunOS 4.1.x 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. A preliminary version is available for OS/2 and Solaris x86. Ports to NeXT 486 and Windows NT are underway. 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. >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. ---------- 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 Dr. Meyer's book, "Eiffel: The Language" (2nd Printing), as the initial definition of the language. The NICE board of directors 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) 2701 Stratford Drive Austin, TX 78746 TEL: (512) 328 6406 FAX: (512) 328 0466 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 9 Princeton Court ISE Inc. 55 Felsham Road 270 Storke Road, Suite 7 London SW15 1AZ Goleta, CA 93117, USA TEL 081 780 1088 TEL (805) 685-1006 FAX 081 780 1941 FAX (805) 685-6869 (publishes a newsletter and holds email darcyh@eiffel.com a quarterly meeting and seminar) 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. 6 Pound Road Hornsby NSW 2077, Australia TEL +61 2 477 6188 FAX +61 2 476 4378 email class@peg.pegasus.oz.au 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 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 +54 1 28 1950 TEL +61 3 785 1122 FAX +54 1 322 1071 or +54 1 963 0070 FAX +61 3 770 0961 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 Information and Math Science Lab Inc. ZumaSoft 2-43-1, Ikebukuro, Toshima-ku 6235 Paseo Canyon Drive Tokyo 171, Japan Malibu, California 90265, USA email fushimi@idas.imslab.co.jp TEL & FAX +1 310 457-6263 TEL +81 3 3590 5211 email 72674.3161@compuserve.com FAX +81 3 3590 5353 Objectif Concept Abstraction (Jacques Silberstein) Passage Cour-Robert 5 18 Faubourg de l'Hopital CH 1700 Fribourg, Switzerland 2000 Neuchatel, Switzerland TEL (41) 37-232977 phone +41.38.25.04.93 FAX (41) 37-464889 fax +41.38.259.857 email 100015.304@compuserve.com ---------- 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. Aug 1 - 5, 1994 TOOLS USA '94, Santa Barbara, California Deadline for papers: 18 March Nov 29 - Dec 1, 1994 TOOLS PACIFIC '94, Melbourne, Australia Deadline for papers: 22 July 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? (Although current Eiffel implementations compile to C or 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. ---------- 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 supplies an emacs-mode to anyone who requests it. Send mail to elisp@atlanta.twr.com to get the latest version. ---------- 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 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.) The Eiffel Booch Components are available for use with TowerEiffel. Most of them can be made safe in the presence of multiple threads of control. They come with testing classes which double as training aids. They include: Data Structures Bags, collections, deques, dictionaries, graphs, lists, maps, queues, rings, sets, stacks and trees. Tools Pattern-matching, search, sort. Support Classes Node, hash table, dictionary, synchronisation, date and time. ---------- 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". -- -- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK | Ph 0772-687525 -- Everything Eiffel: compilers/libraries/publications | +44-772-687525