Okay, I'm probably wandering into a quagmire here. All of our CLI standards experts are traveling or on vacation so I can make egregious comments and then claim ignorance later.
>Rotor *does* have CLS compliance checking, doesn't it? ;-) I don't believe there's really anything a CLI implementation has to do for CLS compliance checking. The CLS is a contract between framework providers and compiler writers which defines a common subset of the CLI that framework implementations should conform to in order to work with the largest number of possible languages. Actual "compliance checking" (if any) would occur in a compiler implementation and the actual implementation behavior isn't specified in either the CLI or the C# standard although the attributes that indicate compliance or non-compliance are specified. I believe the Rotor implementation of the C# compiler is the same as the .NET Framework C# compiler in this area. >I think the ECMA standard required it, last time I looked... This is an interesting point. The ECMA CLI specification does not seem to explicitly state that anything specific has to be done to support the CLS. This makes sense because the CLS is simply a subset of the full CLI specification. Since compliant implementations have to support the entire set of CLI functionality then, by definition, they already support all CLS functionality. For example, in Partition I, Section 6.1, Introduction, the specification states: ----------------------------------------------------------------------------------------- The Common Language Specification (CLS) is a set of rules intended to promote language interoperability. These rules shall be followed in order to conform to the CLS. They are described in greater detail in subsequent chapters and are summarized in Chapter 10. CLS conformance is a characteristic of assemblies that are generated for execution on a CLI implementation. Such assemblies must conform to the CLI specification, in addition to the CLS rules. These additional rules apply only to types that are visible in assemblies other than those in which they are defined, and to the members (fields, methods, properties, events, and nested types) that are accessible outside the assembly (i.e. those that have an accessibility of public, family, or family-or-assembly). ----------------------------------------------------------------------------------------- While it does state "These rules shall be followed in order to conform to the CLS." it does not state normatively that CLI implementations must somehow enforce the CLS. There's also a note in Partition IV, Section 1, Overview which states: ----------------------------------------------------------------------------------------- Note: While compiler writers are most concerned with issues of file format, instruction set design, and a common type system, application programmers are most interested in the programming library that is available to them in the language they are using. The Common Language Infrastructure (CLI) specifies a Common Language Specification (CLS, see Partition I) that shall be used to define the externally visible aspects (method signatures, etc.) when they are intended to be used from a wide range of programming languages. Since it is the goal of the CLI Libraries to be available from as many programming languages as possible, all of its functionality is available through CLS-compliant types and type members. ----------------------------------------------------------------------------------------- Although this looks normative, it's actually somewhat moot: the standardized Frameworks classes conform to the CLS and since a conformant CLI implementation must implement them as specified then, by definition, other Framework implementations of these classes will be CLS compliant. In any case, it is clearly a Very Good Idea that any additional frameworks intended to be shared across a wide range of programming languages conform to the CLS definition. The definition is useful and necessary because the CLI supports functionality beyond that which can commonly supported across many languages. However, my understanding is that the CLS is a simply a formal subset definition and as it currently stands any enforcement/conformance mechanism is the discretionary responsibility of compiler authors. John (I think I'll add the disclaimer twice on this one.) This posting is provided "AS IS" with no warranties, and confers no rights. Il presente posting viene fornito "cosė come é", senza garanzie, e non conferisce alcun diritto. -----Original Message----- From: Fergus Henderson [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 2:34 AM To: [EMAIL PROTECTED] Subject: Re: C# compiler cannot handle interfaces with static methods On 14-Aug-2002, Brad Merrill <[EMAIL PROTECTED]> wrote: > Also, if you start implementing things outside of CLS, think about the > impact on other languages. Eg, what will happen if you class is > instanciated by Eiffel? or Fortran? :) That is not a good argument for not implementing things outside of the CLS. If people want their code to be interoperable with other languages, then they will build their software with CLS compliance checking enabled. Rotor *does* have CLS compliance checking, doesn't it? ;-) I think the ECMA standard required it, last time I looked... -- Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
