Possibility of language data type not mapped to shipped .NET Framework?

Question

Does anybody know of a managed programming language implemented on .NET that contains a specialized data type that is not mapped through to the Common Type System/FCL/BCL or one that does not have a shipped .NET equivalent (e.g. shipped standard types like System.String, System.Int32)?

This question would likely come from the perspective of someone porting a compiler (although I'm not doing that).

Is it as simple as the language creating a new data type outside the BCL/FCL for its specialized type? If so does this hinder interoperability between programming languages that are otherwise accustomed to mapping all their built-in data types to what's in the BCL/FCL, like Visual Basic and C#?

I can imagine this situation might come about if an obscure language compiler of some kind is ported to .NET for which there is no direct mapping of one of its implicit data types to the shipped Framework.

How is this situation supported or allowed in general? What would be the expectation of the compiler and the Common Language Runtime?

Answer 1

Delphi for .NET implemented the Delphi language's notion of class variables (which can hold a reference to a class type), virtual class methods, and virtual constructors (called via a class reference). None of these have any direct analog in CLR - static methods in CLR cannot be virtual, and constructors cannot be virtual.

Since CLR has such a rich soup of runtime type information, these artifacts aren't strictly needed in CLR. If you want to construct an instance of a type at runtime in code that doesn't know the exact type at compile time, you can do that with reflection or other techniques. These features of the Delphi language grew out of the natively compiled Win32 product where runtime type information is limited. This was all implemented on .NET 1.0 and 1.1, long before anything like the DLR came along.

These Delphi language features could be emulated in CLR using reflection, but for performance reasons we opted to implement them directly in IL by creating a "meta class" type that was a sidecar to every class type declared in Delphi. If Delphi code assigned a Delphi class type to a class reference variable, we generated IL code to assign the singleton instance of the corresponding meta class to the variable. Virtual method calls via the class reference variable were codegen'd as IL virtual method calls on the meta class instance, which bounced to the actual static method implementation in the corresponding class type. This allowed the class virtual method calls to still behave polymorphically (to call the implementation appropriate to the type of the instance used to make the call) and with minimal runtime performance cost. This implementation was also type-safe and verifiable.

These virtual class method features were only applicable to classes declared in Delphi syntax, and only useable in Delphi syntax. I believe the meta types were marked as non-CLS compliant so that other .NET languages would (most likely) ignore them when using classes created in Delphi. Other .NET languages could not make use of these Delphi specific language features (unless the developer was really determined and climbed through the scaffolding to make the appropriate calls to/through the ugly named meta classes)

In general, you should not expect other languages to make use of non-CLS artifacts created by/for your language. If you want other languages to make use of stuff created by your language, you will need to figure out how to represent your special sauce in a way that can be represented in a reasonable way in CLS compliant terms. That may not be possible depending on the nature of the special sauce.

Delphi virtual class methods were available to other .NET languages as normal static methods. The polymorphic nature was not exposed to other .NET languages largely because CLS (nor other languages) simply can't express the notion.

Ideally, every language would be able to express every imaginable construct equally well. But in reality that's not the case. Some graphing functions are easier to express in cartesian coordinates, while others are vastly simplified by using polar coordinates. The same is true for programming languages.

It's ok to invent new means of expression in your own language even when it's implemented on CLR. Just be sure to keep a clear definition of what your types look like to programmers working outside your language if you expect your language's code to be called by others. Your implementation will have a duality: how things look to users of your language, and how things look to users outside of your language.

Footnote: I don't believe any of this applies to the new Delphi product for .NET, Delphi Prism. I don't think Delphi Prism supports virtual class methods.

Answer 2

Not really. Any language has the ultimate burden of having to be able to run on commodity hardware to be successful. The CTS is a pretty good model for types that can be efficiently handled on current hardware.

What may be needed is a big chunk of runtime support to adapt between the language's type system and the CLI's. A classic example is the DLR, the runtime support system for dynamic languages like Python and Ruby. It essentially does what such a language interpreter must do as well, it has comparable perf. No tricks btw, everything is pure C# code.

Such a runtime support library may get slow when the language has features that are not available at all. Multiple inheritance for example. It is natively 'supported' by the CLR and JIT compiler. You can take about any standard compliant C++ program that uses MI, run it through the C++ compiler with the /clr option and you'll end up with an assembly that contains pure IL that will be just-in-time compiled at runtime. By no stretch of the imagination could you call the result a managed program, it won't be verifiable and it won't use the garbage collector. Solving that is going to require a support library that's going to have to emulate multiple inheritance. Possible, I doubt it will be competitive.

Answer 3

Well, there's c++/cli. There you can create c++ classes that are not visible in .net. Is that what you're after?