Re: Microsoft .NET and its IL

Lieven Marchand wrote:
>
> Also, the IL doesn't aim to be all that general. Already one of the
> languages targeted, Eiffel, had to have some details
> w.r.t. inheritance changed to fit in, resulting in a language called
> Eiffel#. Details are on www.eiffel.com. And the object system of
> Eiffel is relatively mainstream.


Actually Eiffel's object system is far from mainstream. The devil is in
the detail, and massively so:


1. Feature renaming. Eiffel "features" (routines and attributes) can be
renamed when inheriting. This means that the language system must
identify all features by name and "seed class" where the feature is
introduced (simple), and all tools that generate names from intermediate
code must apply the correct transformation from internal name to locally
valid name (this is a stinker).
2. Extremely generous multiple inheritance, including multiple interface
inheritance. .net code would have to simulate this using delegation.
(That's a good technique to implement MI anyway, but you lose
optimization opportunities that way.)
3. Genericity (aka templates aka type parameters) is based on a
compile-it-once model (i.e. you have object for LIST[], the compiler
doesn't generate extra code for LIST[INTEGER] and LIST[CUSTOMER] as
would be done for C++). This is great for compile-time checking and for
generating compact code, but it's also much more powerful than what C++
offers, and .net doesn't directly support C++, much less Eiffel.
4. Assertion checking. Eiffel mandates that a failed precondition check
raises an exception *in the caller* (a precondition violation is a
failure on the caller's side after all). I heard some rumors (nothing
substantial really) that the Eiffel# team had to undergo some extra
contortions to make it work as desired.
5. Assertion checking again: in practice, Eiffel code is heavily laced
with assertions, based on the guarantee that all Eiffel compilers can
disable assertion checking with the flick of a link-time (or even
run-time!) switch, and at an extremely fine granularity (down to a
single feature in a class). So Eiffel programmers tend to write
computation-heavy assertions, sometimes even O(n^3) assertions on O(1).
Achieving the same ease of use under .net is a pain in the neck.
6. Assertion checking again: Classes can have invariants, which are
assertions to be checked upon every routine exit (and on routine entry
for reasons too obscure for this discussion). Subclasses can add new
invariants, so the compiler must generate a polymorphic (i.e. "virtual")
routine. Again, debuggers and the like must take care not to display
this routine as part of the class's interface.
7. Error reporting due to failed assertions: due to renaming, the name
of the failed routine may differ dynamically. This makes it difficult to
generate appropriate error messages when an exception is never caught.


None of these problems are a real show-stopper - it should be safe to
assume that .net is Turing-complete after all. But every problem
carries a solution that has some minor negative impact, and on the
whole the effect can be disastrous. I guess that's the reason why
Eiffel# is (Eiffel minus some language features).


Indeed the Eiffel# team seems to have been busily inventing ways
around problems until early this summer (if they aren't still devising
ways to make Eiffel# more like Eiffel).


> I'd like to see attempts to accomodate really different OO systems
> as CLOS or Cecil. Or prototype based ones as Self.


I think the grand sweeping differences are easier to get under
control. You know what you're up to right at the beginning of the
project, and you can set up a language-specific sandbox to address the
problems. I think it's much worse if you have tons of little
problems. In this situation, it's unlikely that you'll have a good
idea how the final system will look like, so you'll be adding little
ad-hoc solutions until they have totally overgrown the basic run-time
system. YMMV.


Regards,
Joachim

Return to the comp.compilers page.
Search the comp.compilers archives again.