[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .NET CLR? was no subject

On Wed, 2002-03-06 at 18:50, Michael Vanier wrote:
> Eric Kidd mentioned the case of Eiffel.  My understanding is that even
> though the Eiffel people managed to create a .NET version of Eiffel with MI
> and DBC, they had to go through some pretty major hoops to do so.

I'm still waiting for my "Compiling for the .NET CLR" book with all the
answers. ;-)

As I understand it, you can implement multiple inheritance under the CLR
by basically ignoring the CLS (the "Common Language System", which is
basically the shared object model) and building your own vtables by
hand.  The instruction set is reasonably rich--and "unsafe" code doesn't
need to undergo security checks--so your generated code can do all kinds
of hackish things.

Some random notes:

I'm trying to get DAS98-style table-based generic functions running on
the CLR.  Unless I'm misunderstanding the instruction set, I can do this
at the cost of a few extra cycles.  Not ideal, but not a total disaster,
either.  I'll let you know how things turn out.

The 'tail.' instruction prefix is *seriously* nice, especially for LISP
and Scheme hackers.  On the downside, you pretty much have to live with
a standard stack frame, which makes it harder to implement multiple
values cleanly.

Since my work doesn't rely *too* heavily on tagging, I haven't looked
into this issue yet.  I don't know whether the CLR GC will get grumpy if
you start tagging immediate values.

So, yeah, you do have to jump through some hoops.  But overall,
compiling to the CLR is probably more flexible than compiling to C.  And
it's certainly more flexible than compiling to the JVM.

> It appears that the "common type system" really means "common type
> system for a language sufficiently similar to C#".

Yes.  But you can more-or-less ignore the CLS (and heavily abuse the
CTS) and still run your code under the CLR.

Don't think of the CLS as your object model; it simply won't work for
any unusual or exciting language.  Instead, think of the CLS as your
foreign function interface and your external component model.

So a hypothetical Dylan-for-CLS compiler could support multiple
inheritance, generic functions, and all sorts of other goodies (in
theory; ask me again in two months).  But if you wanted to call Dylan
code from Visual Basic, or vice versa, you'd have to stick to the CLS
and provide a way to declare attributes.

Again, I'm far from an expert on these matters, and I may discover some
nasty, lurking surprises which prevent me from implementing my favorite
lightweight language on the CLR.  But so far, it's a fairly interesting

David Simmons can tell you more about SmallScript and the CLR.