Talk:Common Language Infrastructure

cli

Common language infrastructure (CLI)is a term which gives no results when run on the Microsoft web site]. But Common language runtime is not much better (4 hits). And Common language runtime gives a lot of hits, but they seem to be Java related.

A general google search on Common Language Infrastructure and Common Language Runtime gives a considerable amount of results. But sorting out needs its time.

I would like to see an article which translates the Microsoft speak into commonly known computing terms. The stub above is a first attempt at this. Perhaps it should be moved to another heading. -- Kwaku

CLI as seen with the eyes of a Java proponent: http://www.javalobby.org/clr.html (link put here to consult for further work on the article)

---

I removed some stuff because it was copied without even some decent formatting from http://hosting.msugs.ch/dotnetrox/vb/Ch01.html -- Jan Hidders 20:47 Sep 7, 2002 (UTC)

Inter-language integration in the open source world

One of the strengths of CLR seems to be that it allows lots of different languages to be integrated and call each others' code. The code to produce and use DLL assemblies in many languages is quite simple. Is there any similar "inter-language integration" layer in Linux, or in the open source world? I have used SWIG and Boost, however, I'm more asking whether it is possible to not merely export C++ code into various languages, but rather, to share code between pairs of arbitrary languages. For example, is it possible to take a CPAN Perl module and call it from Python, or export a Tcl module and a Ruby module and call each of these from clisp? If the necessary technology to do this does not exist, then I'd like to know that as well. Thanks. Connelly 00:08, 21 July 2006 (UTC)

The easier part of the problem is the parameter-passing mechanism: different languages use different techniques to pass values or references to called methods. Some push only references, while others push values or references depending on the parameter type and options. So its a difficult problem even if the parameter types are limited to integers and reals. Stepping up the complexity a bit, consider dates: each language has its own internal representation of a date value that would be incompatible with that of another language. Decimal values, ditto. And when you get to passing references to structure memory like objects, forget it. Perl would have no way to interpret an instance of a Python object: the internal representation of that object is totally foreign to Perl.

COM and COBRA were earlier attempts to support inter-language calls by forcing representations into a commonly understood format. They've had limited success due to complexity and inherent limitations. COM is still used pretty commonly on MS platforms CORBA is the non-Windows implementation of similar technology, but I have the impression that is a failed technology. (I'm sure someone will disagree, and that's fine.)

Hope this helps.

Thanks, that does help. I noticed that if I google specific pairs of languages, such as Tcl+Python integration, I can often find mechanisms for working with the given two languages at once, such as [1]. Perhaps in the open source world, inter-language integration is typically done over the Web: via app-specific protocols, SOAP, CORBA, XML-RPC, .... That is a fine answer; I just wondered if I was naive and didn't "know" how inter-language integration was done in the OSS world. There are also some discontinued research projects like ILU and Flick which seem to be focused on this same goal.

Found what I was looking for. The open source world has copied Microsoft's OLE and COM with technologies such as KPart and Bonobo. - Connelly 23:18, 2 August 2006 (UTC)

Category

I noticed that the article has no category. Maybe separate Category:Microsoft .NET should be created? --Derbeth 19:42, 3 Apr 2005 (UTC)

I've put it in the already-existing Category:.NET programming languages. ··gracefool |☺ 05:13, 5 Apr 2005 (UTC)

My understanding is that the CLR (Common Language Runtime) is not technically a virtual machine. It does not run IL code, it loads and compiles it. The architecture is designed to provide a platform-neutral layer similar to that provided by Java's Virtual Machine, but the mechanism is different.

Implementations

I've repositioned the implementations section to logically follow Standardization and Licensing. A question regarding MS .NET FW there: why is it called 'commercial' if it's available for free download? --tyomitch 08:45, 2 September 2005 (UTC)

I labelled it as such because it is a heart of their commercial .NET offering, and to emphasize the fact that it's a closed-source implementation Microsoft uses for profit. Hope that makes some sort of sense. :) -- Foofy 18:12, 4 October 2005 (UTC)

Implementations / CLI and CLR

I'll address this on the project page, but the CLI is a spec, and the CLR is an implementation of CLI plus libraries, etc., so it makes more sense to put the implementations in the CLR article. -- Foofy 18:12, 4 October 2005 (UTC)

Hi Foofy! Long time! Does Foofy got something to do with Footbal fan?! ;) I suggest that the section to be kept as it is and develop it in the CLR article. We can add later on a reference to that from here. Cheese -- Svest 18:57, 4 October 2005 (UTC)  ^{Wiki me up™}

This article says that the CLR "contains aspects outside the scope of the specification" however the CLR article says that the CLR is an implementation of the CLI. Those statements seem contradictory to me. 76.87.181.194 04:24, 16 November 2007 (UTC)

patents

Can we get some more information about the patents held on the Common Language Infrastructure? They're pretty significant for projects like DotGNU and Mono. Is there a chance these projects will one day be attacked my Microsoft and forced to stop? Herorev 00:26, 23 September 2007 (UTC)

This open question was finally answered with Microsoft putting C# and the CLI under the Microsoft Community Promise

There is still a lot of doubt over/room to misinterpret the CP, especially regarding Mono. The absolute statement that programming with it has been made completely safe is anything but definite, and should probably have a dubious tag. C# for instance is only protected by the standard for an older implementation, and the CP doesn't include quite a few things, like Windows Forms, needed for some functionality. Raider480 07:57, 14 October 2012 (UTC)

sentence

While Microsoft and their partners hold patents for CLI, ECMA and ISO require that all patents essential to implementation be made available under "reasonable and non-discriminatory (RAND) terms."

does that sentence make sense? —Preceding unsigned comment added by 201.152.52.113 (talk) 08:51, 11 December 2007 (UTC)

Common Language Specification

The page Common Language Specification linked to in the Overview has only the same information as the Overview's paragraph. Should the page be removed, with a redirect to the Overview? Also, should it have an inline link to MSDN's page onCommon Language Specification and/or the link in the References section?Tagus (talk) 05:45, 16 August 2009 (UTC)

I've redirected it. - MrOllie (talk) 13:36, 7 September 2009 (UTC)

Dynamic typed languages

"No Support For" is a bit misleading? Iron Python is a CLR implementation of Python, which is a Dynamic typed language. So I guess you don't need support for dynamic typed languages in order to support dynamic typed languages.

Whatever. It just doesn't seem like a clear statement. —Preceding unsigned comment added by 203.206.162.148 (talk) 07:35, 11 January 2010 (UTC)

Mention CLR

The page should mention the relationship between CLI and CLR.
Encyclopedant (talk) 19:58, 1 January 2019 (UTC)