Lambda the Ultimate

Eiffel# versus Eiffel

This brief introduction to Eiffel raises a few interesting issues for its integration into the .NET Framework. Maybe the most challenging is the support for multiple inheritance, since the common language run time was designed to support single inheritance only. Because Eiffel# must only use the common language run time, it has to follow the .NET Framework object model and thus disallows multiple inheritance of effective or partially-deferred classes. You may, however, multiple-inherit pure-deferred classes; in which case, they are generated as interfaces. The partially-deferred or effective parent class, if any, is the base type.

Eiffel# does not support the new Eiffel constructs that were added after the publication of the current edition of Eiffel: The Language. These constructs include agents and related classes, generic conformance, and generic argument creation.

Another mismatch between the common language run time and the Eiffel object model is the lack of support for covariance in the former. For this reason, Eiffel# does not support covariance. That is, you cannot redefine the types of the arguments or the results of the features in the descendant of a class.

The last difference between the two languages lies in the semantics of expanded types. Expanded types in the .NET Framework are directly mapped to the so-called value types. Although fundamentally the same, Eiffel expanded types and the .NET Framework value types do not behave in exactly the same way. In particular, value types are sealed, meaning that one cannot inherit from them. As a result, you cannot inherit from expanded types in Eiffel#.

There are no other differences between Eiffel and Eiffel#; in fact, Eiffel# supports contracts, exception handling, and genericity, some of the hallmarks of Eiffel programming.

The other issues raise the same question...

I'm confused about the comment on types. I don't know what expanded types are, but is sounds as though .NET imposes its own type system. But if OCaml can be written using .NET then they must be able to implement various things that don't occur in Java/C++ like languages (hence my confusion) (or is there, say, some match between whatever template-like support there is in C# and, say, polymorphic types?) (and maybe that question demonstrates just how little I know!)

Andrew

That seems pretty damning - I think it reflects .NET being targetted as a JVM replacement rather than a basis for "any" language.

I'm confused about the comment on types. I don't know what expanded types are, but is sounds as though .NET imposes its own type system.

From a programming standpoint, it really helps if the primitive types can be treated as an object. You should be able to even subclass a primitive type to add additional behavior as required. If you look at some of the Java API's you will find that the number of methods has exploded in some of the classes because they have to contend with all the various primitives as well as a base object.

OTOH, if you treat the primitives as objects, this can cause a massive amount of overhead. Everytime you want to add two numbers, you'd have to send an 'add' message to an integer object. The classic Smalltalk (and Lisp?) VMs do have optimization tricks to discover when an integer can be treated as a primitive and when it must be treated as an object. Although similar in principle to the unblocking of C#, Smalltalk allows much more flexibility in subclassing and extending the base types.

Eiffel treats the primitive base types as Expanded Types. What they mean is that class is expanded within the containing class. That is, an expanded type is not an independent object but is expanded as part of the class which contains the 'primitive'. Hence, an integer is not an independent object which responds to messages, but is rather an embedded object within the class that holds the integer.

This allows the optimization for primitive manipulation to be handled automatically. It also provides a mechanism for being able to subclass primitives with little to no problem. It does introduce some complexity in assignment operations - expanded types can not be pointed to but are copied in toto - but Meyer did a pretty good job of making the rules pretty clear.

IMO, Expanded types were a brilliant compromise between the primitive framework of Java and the everythings an object in Smalltalk. C# is an improvement on Java in this area, but Eiffel expanded types beat C# blocking any day of the week.

But if OCaml can be written using .NET then they must be able to implement various things that don't occur in Java/C++ like languages