Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!w-edwinh
From: w-edwinh@microsoft.UUCP (Edwin HOOGERBEETS)
Newsgroups: comp.lang.eiffel
Subject: Problems with Eiffel design
Message-ID: <10036@microsoft.UUCP>
Date: 21 Dec 89 23:34:33 GMT
Reply-To: w-edwinh@microsoft.UUCP (Edwin Hoogerbeets)
Organization: Microsoft Corp., Redmond WA
Lines: 136


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)

Edwin