How Dot Net Languages Differ

"The Microsoft .NET platform defines a CommonLanguageSpecification (CLS), a sort of lingua franca that ensures seamless interoperability between CLS-compliant languages and class libraries." Languages that implement and map their language to the CLR may interoperate and play on the CLR. It's up to each language how much above the CLS to implement and how to map it to their syntax. In order to play in the managed environment and be able to support the CLR features, inheritance from one language to another and passing exceptions across the language boundaries, they have to support the CLS specification as listed above. This ensures that like Java, each type is precisely sized and typed.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguidnf/html/cpconwhatiscommonlanguagespecification.asp

Syntax of DotNetLanguages is clearly different. But it seems you can transform a program written in one languages to another using AST transformations. Are they different languages or one language with different syntaxes?

Is this different from asking how two TuringComplete languages are different?

Yes, it is different. The differences between any two DotNetLanguages cannot be as great as they can be between two arbitrary programming languages. Not every programming language can be implemented efficiently on top of DotNet.

I don't believe the limitations of assembly language have restricted the magnitude of differences between languages, so why should .NET be any different? Think of the CLR as a more language-friendly assembly language. Efficiency of implementation is a small price to pay in return for interoperability with other languages. Besides, the mapping of more esoteric language features to the CLR should only be a problem for the compiler designer, not the programmer.

AssemblyLanguages don't have to be portable or be designed to enforce security constraints (leaving aside the issue of whether the CLR actually succeeds in enforcing security constraints). These additional requirements make it much harder to design something that efficiently supports a wide range of languages, and it can be argued that CIL/MSIL doesn't do a very good job. In any case, the design of CIL/MSIL is very different from assembly, and it is considerably less friendly to some languages than assembly is.

Can you implement naturally PrologLanguage or IconLanguage in CommonLanguageRuntime?

Maybe. Well, no but sort of yes.

See

http://www.cs.mu.oz.au/research/mercury/information/dotnet/objectworld_flyer.html ( BrokenLink )

for notes on running "Mercury on .NET" Try instead:

http://www.cis.unimelb.edu.au/

"Mercury" is apparently similar to Prolog, and they're working with Microsoft to extend .Net to support it.

Microsoft Research are also modifying the .NET CLR to better support pure functional languages.

Some OtherDotNetLanguages are purely FunctionalProgrammingLanguages, or purely DeclarativeLanguages.

The mystery is how you implement complete objects with state in these languages? Does anybody have an idea?

Ah! It is precisely because CLR will try to realize AllPossibleMachineModels? that it is destined to fail. It's simply a matter of BitingOffMoreThanYouCanChew?. Or, NeverEatAnythingBiggerThanYourHead?.

Each ".Net" compiler maps its input language to the subset of possible CLR programs. It is up to each language how much of the CLR to expose. This is much like a "real" compiler, which maps your high level language program to some point in the subset of all possible machine language programs.

So, generally speaking, having .Net's CLR does not make it easier to translate programs of one source language to another (except for features directly supported by CLR), because each maps to a different subset of possible CLR/machine language programs.

Although at first it might seem that you can implement every possible CLR program in CsharpLanguage, it does not expose all of the CLR. For example, all C# exceptions are represented by an instance of a class type derived from System.Exception, whereas the CLR imposes no such restriction. All C# arrays are zero-based, whereas the CLR allows arrays with non-zero lower bounds.

In understanding .NET, CLR and C#, it's interesting to look at a .NET feature which is supported by C# but which does not appear to be documented in the CLR docs: indexers. For example, the Request object, which is an instance of the HttpRequest? class has a couple indexers (string and numeric). Request["Name"] is meaningful, but apparently undocumented. Furthermore, the documented methods provide no exact equivalent and instead imply that your only option involves a pathetic dive into numeric indexing.

C# indexers are exposed to other languages as get_Item()/set_Item() methods.

('Request("Name")' also works in VB.NET (arrays use parenthesis in VB, not square brackets). It's possibly undocumented because it's a hold-over from ASP-classic. MS sometimes plays games to "encourage" people to upgrade.)

CategoryDotNet CategoryProgrammingLanguageComparisons