w-edwinh@microsoft.UUCP (Edwin HOOGERBEETS) (12/22/89)
I have a few questions about the Eiffel design that I hope people on the
net can address.
First, Bob Weiner posted a message about the GNU Emacs eiffel package he
wrote. In it, he mentions version 2.2 of Eiffel and the list of
keywords the GNU Emacs package supports seems extended. Where can I
find out about newer versions of Eiffel? I have the book "Object
Oriented Software Construction" by Bertrand Meyer already.
Second, there are a few problems with the Eiffel design as I see it.
These problems arise because I wanted to write an operating system in
Eiffel (we are thinking of rewriting minix) and we want to write a
native compiler for it.
1 No bit fiddling operators
This problem may be addressed in v2.2 of Eiffel (according to the
above mentioned posting by Bob) I see a xor operator, which may or may
not mean the bit fiddling operator.
Some device drivers and such require bit fiddling.
How do you get around this restriction in Eiffel? Use external C
routines for bit fiddling? Perhaps I should define a class BITFIDDLE
which inherits from INTEGER, and provides access to the C `&', `|' and
`^' operators?
Perhaps, the lowest levels of the OS should be in assembler, the
device drivers in C, and the higher level stuff in Eiffel?
2 Special cases abound. (Create, Result, Current, Forget, INTEGER, etc)
Did these have to be special cases? What is the rationale behind them?
3 Arrays are not intrinsic
This means eiffel must depend on external languages for array
implementations. On page 451 of Meyer's book, in appendix A, the
implementation of the ARRAY class is described as using C functions.
Is the concept of "arrays of objects" not compatible with the Eiffel
philosophy?
4 The syntax is ugly. There are too many shift/reduce and reduce/reduce
conflicts from yacc and such parser generators for the Eiffel
grammar.
Xenix yacc reports 311 shift/reduce and 199 reduce/reduce conflicts.
Is there a better way to parse Eiffel? Bison? A hand crafted parser
perhaps? ll(1) parsers? Recursive decent?
5 Eiffel assumes the size of storage for the class INTEGER and for a
reference to an object are the same
On page 452 of Meyer's book, the external C routine "allocate" is
declared as class INTEGER, when it is actually a pointer to memory. One
thing we should have learned by now is that pointers (ie. references)
are not necessarily the same size as integers.
This incompatibility is especially true on Intel architectures. A
"far32" pointer on a '386 may be 6 bytes, while an integer is still 4
bytes.
This is the major problem, since it would affect an Eiffel to C
implementation, as well as a native compiler, on a PC.
On a slightly different topic:
We (some friends and I -- not Microsoft) are thinking of writing the
native Eiffel compiler, first written in C with the second version
written in Eiffel itself. Code generation modules would be written for
386/ix, AmigaOS, Minix, and perhaps OS/2.
The Eiffel implementation could be really beautiful:
class MODULE
-- a module and its compilation routines
export
compile, short, flat, extract_interface
feature
modulename : STRING;
-- name of the module or class to compile
intermediate_representation : IR;
-- IR is the traditional intermediate code along with its own
-- symbol table
Create is ... end -- get module name from arguments
compile(module : STRING) is
do
intermediate_representation.Create(modulename);
-- do the equivalent of the first pass to create the IR
intermediate_representation.optimize;
-- do nice tree optimizations and such
intermediate_representation.Forget;
-- do equivalent of code generation, peepholing, assembling
end
short is ... end -- do a short on this module
flat is ... end -- do a flat on this module
extract_interface is ... end -- extract the interface info for
-- use by es to determine "make"
-- information
Forget is ... end -- clean up
end -- class COMPILER
Pretty neat, I'd say! The Forget routine for an IR could be deferred,
and thus, have multiple implementations which are different code
generators for each OS. (Is that possible and/or a good idea?)
One problem I can see is that the name "Eiffel," just like "Ada," is a
trademark. (see the page xvi of Meyer's book) I don't know about the
legal ramifications, but does this mean I would have to call the
compiler something else, or do I have to get it certified? (We plan to
make it freely redistributable, at least at first)
Is ISE Inc. on the net?
Please post if relevant to everyone, otherwise email to
edwin@watcsc.waterloo.edu or uunet!math.waterloo.edu!watcsc!edwin
with any comments or suggestions. Thanks!
(the microsoft account is going away soon -- please do not mail here)
Edwinbertrand@eiffel.UUCP (Bertrand Meyer) (12/22/89)
From <10036@microsoft.UUCP> by w-edwinh@microsoft.UUCP (Edwin Hoogerbeets): > We (some friends and I -- not Microsoft) are thinking of writing the > native Eiffel compiler, first written in C with the second version > written in Eiffel itself. Code generation modules would be written for > 386/ix, AmigaOS, Minix, and perhaps OS/2. > > (...) > > One problem I can see is that the name "Eiffel," just like "Ada," is a > trademark. (see the page xvi of Meyer's book) I don't know about the > legal ramifications, but does this mean I would have to call the > compiler something else, or do I have to get it certified? (We plan to > make it freely redistributable, at least at first) > > Is ISE Inc. on the net? This has been said more than once before but let me repeat it loud and clear: not only is it permitted to write an Eiffel compiler without any specific authorization from Interactive Software Engineering, but we enthusiastically welcome such endeavors. Eiffel is indeed a registered trademark of Interactive Software Engineering and we do require that uses of the name (e.g. to advertize a compiler, interpreter or programming environment) clearly bear the acknowledgment of this fact. This is the only debt you will have to us except for eternal gratitude. I hope this is clear enough. Our policy is much more liberal both than DoD's attitude towards Ada (for which you cannot use the name unless you pass an expensive and complex validation process) and AT&T's Unix policy. To be sure, arguments may be found for the restrictive approach; but we decided against it in the Eiffel case for both scientific and business reasons: - Scientifically, the entire goal and thrust of our work is to improve the quality of the software produced in the world, and the quality of the production process. It would absurd to think that a single team can cover all the tasks to be done. Our aim is to make the technology succeed, not to remain the sole holders of the sacred truth. The more smart people join the fun, the merrier. - As for the business perspective (which is part of the picture since our independence from the big powers of this world and from the associated politics and compromises, a key component in the scientific integrity of Eiffel, also means that we must make money), I'll be quite frank: at Interactive, we think that Eiffel industry is going to be so huge in some time from now that we'll make more than a decent living, thank you, even if we control only part of that industry. By the way, we have been discussing the possibility of hosting a workshop on Eiffel implementation techniques, probably in Santa Barbara sometime in 1990. The workshop would be open to implementors or earnest potential implementors of Eiffel; it would be for a fee. I would appreciate if anyone seriously interested in this idea could indicate it to me by e-mail. Mr. Hoogerbeets raises the question of validation. We have indeed started some preliminary work on the idea of a validation suite. Use of the Eiffel name will not, however, be conditional on satisfactory completion of an official validation process. (If anyone is interested I'll explain why we decided against such a requirement.) When the suite is ready, we will indeed offer a validation process; tools passing the process will be entitled to a label such as ``conforms to the official Eiffel validation suite''. Until the validation suite is ready, implementors will of course face the practical problem of checking their implementations. There is enough Eiffel code around to support this effort. In particular, I can't imagine anyone engaging in such an effort without acquiring a copy of Interactive's compiler and environment, which comes with many examples, demos and other Eiffel classes, all quite suitable for helping to validate an implementation. This is not as systematic as a validation suite but provides a good beginning. From another part of Mr. Hoogerbeets's message: > 4 The syntax is ugly. There are too many shift/reduce and reduce/reduce > conflicts from yacc and such parser generators for the Eiffel > grammar. > > Xenix yacc reports 311 shift/reduce and 199 reduce/reduce conflicts. > Is there a better way to parse Eiffel? Bison? A hand crafted parser > perhaps? ll(1) parsers? Recursive decent? Let me take exception to that. First I do not believe that ease of yaccisation is a measure of syntax beauty or ugliness. Furthermore I had always thought that Eiffel's syntax was recursively quite decent. But this is not the point: what Mr. Hoogerbeets is describing is his Yacc grammar for Eiffel, not the Eiffel syntax! Eiffel does admit Yacc grammars without any shift/reduce or reduce/reduce conflict at all. One example of such a grammar is the one we use in our current compiler (which, I am ashamed to admit, is still Yacc-based). Don't just take my word for it. The following is a special New Year gift reserved for all faithful Eiffel netters: watch out in this very space for the full, unadulterated, unabridged, uncensored Eiffel Yacc grammar (all natural, no preservatives or chemicals added), directly and faithfully extracted from Interactive's very own Eiffel compiler through the expert hands of Jean-Marc Nerson, who will post it sometime during the next few days. -- Bertrand Meyer bertrand@eiffel.com