[Mono-list] Implementing ECMA CLI vs Microsoft's .NET Framework

[Sam Ruby]

Peter Drayton wrote:
>
> Would it be correct to say that Mono is not aiming to be an
> implementation of the ECMA CLI, but rather Microsoft's .NET Framework?
>
> I ask because the trend on this list seems to be towards replicating
> .NET as a whole, not the ECMA CLI. While this is interesting and useful
> in of itself, unfortunately it means that the Mono efforts aren't really
> a validation of the completeness of the CLI specs. IMHO this is a pity,
> since validating the specification through implementation is really
> important if the development community is going to use the CLI as a
> general-purpose computing platform longer-term.
>
> OTOH, this means that Microsoft's Shared Source implementation, when it
> arrives, will fill a valuable niche (assuming it sticks to just what's
> in the CLI). I'd like to see a non-MS implementation do the same thing,
> though... :-)
>
> If Mono wanted to fix this, I'm sure it could be done: this would
> involve instituting coding guidelines like "CLI types can only depend on
> other CLI types", "don't use method signatures that aren't in the CLI
> from within CLI types", possibly some preprocessing to break out the
> CLI-compliant & non-CLI-compliant methods, etc.
>
> This would need someone from Ximian to take up the cause, though - if
> not, it will just become a "big ball of mud", with .NET and CLI types
> inextricably linked. Is it worth the effort? Personally, I think so, but
> admittedly my interests lie more in seeing a solid CLI implementation
> that we can port *everywhere*, rather than purely a .NET clone on Linux.
> Of course, the former does not preclude the latter, it's just a matter
> of priorities.
>
> Comments? Am I a community of 1 in my hopes for the CLI? :-)

You might find it productive to spend a few minutes reading the first three
pages of Partition IV.
(http://msdn.microsoft.com/net/ecma/Partition_IV_Library.pdf).  In short,
the CLI contains a number of profiles, and a conforming implementation need
not implement all of them (for example: a PDA may not have floating point).
Adding a profile can involve adding methods to an preexisting class.

Another thing to contemplate - what is being standardized at this time in
ECMA TC39 represents our best guess on what is a reasonable core.  Only
real life experience will validate how well we do.  An independent
implementation (or three!) would provide either a extremely valuable
validation of this, or extremely valuable input as to what should be added
in the next cycle.

A final thought - if you look at JDK documentation, you will see
annotations such as "introduced in JDK 1.2".  One thing that (IMHO) opinion
would be extremely valuable is a proposal for a standard set of metadata
which enables the one to determine what profile a given method belongs to,
and what version of that profile.  This would enable compilers to provide
warnings (e.g., this code contains references to floating point - and may
not run on compact devices).  Such a proposal would have to be cognizant of
the potential footprint and runtime overhead associated with such metadata.

- Sam Ruby