🚀 go-pugleaf

	In <1864@clyde.concordia.ca>, marcap@doyle.cs.concordia.ca (Marc Pawlowsky)
voices concerns about basic types and their use as parents in inheritance.

	I essentially agree with his observations. To reconstruct the sequence
of events:

	- In the original language design, as reflected in ``Object-Oriented
Software Construction'', four types (INTEGER, REAL, BOOLEAN, CHARACTER)
were treated specially, i.e. outside of the object-oriented context.
The reason was twofold: a concern for performance; and a feeling that
``everyone knows about integers and booleans anyway'' and that using the OO
framework to handle them was overkill.

	- After a while we recognized that it was in fact unpleasant to have
this ``magical'' status for basic types, and that (thanks to expanded types,
infix/prefix operators and constrained genericity, among others) it was indeed
possible to have a fully consistent type system, elegantly covering basic types as
well as user-defined types, without necessarily sacrificing implementation
performance.

	As a result, the basic types are treated as ``quasi-normal'' in the
release available since last summer (2.2). Internally, however, they are
still handled specially so as to guarantee a high level of efficiency
(3 + 4 is theoretically a routine call, but few Eiffel users would want it
to be implemented that way!). In fact, this part is one of the trickiest in
our implementation as we try to reconcile elegance of concept with efficiency
of implementation. Furthermore, there are still many carryovers from the
original implementation. For example (as pointed out by Norman Shelley
and others) having a function ``abs'' (absolute value) for integers
and a different one, ``rabs'', for real numbers, is anathema to the
object-oriented approach. I am not particularly proud of that one (which,
fortunately, will be easy to correct; it just escaped our attention).

	As we continue improving and generalizing the implementation, we
will strive to achieve the degree of generality desired by Mr. Pawlowsky
and other writers (and Eiffel users such as ourselves). Although we would
like INTEGER et al. to be conceptually treated exactly like any other
class-based expanded types, we cannot promise that ALL restrictions will
be lifted soon. We want Eiffel to remain implementable with a very small
performance overhead over something like C, and some tradeoffs need to be
made for this goal to remain realistic.
-- 
-- Bertrand Meyer
bertrand@eiffel.com