In the current market, developers use varied programming languages to develop their applications. Each of them may support different features and types, so the language interoperability is hard to achieve. However, any .NET language that targets the .NET Common Language Runtime (CLR) will benefit from its built-in support for language interoperability. CLR specifies and enforces a common type system (CTS) for all .NET languages, which means each of them must follow CTS rules to define and use types. The usage of types is consistent across .NET languages; since all type information is stored and retrieved in the same way, the CLR can execute multiple languages in one .NET application.

But there is still some barrier in .NET language interoperability, because each .NET language uses CTS to support its own unique set of language features. There is no guarantee that the calling code written in one language can be fully accessed by the caller language. For example, if one language provides support for unsigned integers, you can design a field with type UInt16; but from a .NET language that has no concept of unsigned integers, that field won't be useful.

To ensure that the component developed in one .NET language can be fully accessible to any other .NET languages, the .NET Framework provides a Common Language Specification (CLS) that describes a set of features commonly needed by any .NET language. In other words, it defines the minimum language requirements that must be supported by any .NET language.

Therefore, to make PowerScript a .NET language, we must ensure that it is CLS-compliant.

In CLS terminology, there are three different roles: framework, consumer, and extender.

• A CLS-compliant .NET library is called a framework. The framework will have a guarantee of interoperability across different .NET languages; therefore, it will have a wider customer base than libraries that are not CLS-compliant.
• A language that enables users to use the CLS Framework is called a CLS consumer, but the consumer can't extend the CLS Framework.
• A language that lets users use and extend CLS Framework is called a CLS extender, which is a superset of a CLS consumer (everything that applies to a CLS consumer also applies to CLS extenders).

The detail information can be referred to as the Common Language Infrastructure (CLI) Partition I.

In PB12, the PB .NET assembly/Web Service will be targeted as the CLS Framework. PB's classic IDE will be targeted as the CLS consumer. The new WPF workshop IDE will be targeted as the CLS-compliant extender that lets users consume and extend the .NET CLS Framework and produce PB's own CLS Framework (PB .NET assembly/Web Service) for consumption by other .NET languages.

Figure 1 shows the relationship among CTS, CLS, and various .NET languages. As you can see, all .NET languages fully support CLS features and partially support their own set of CTS features. They have some common features, but they all have their own unique features as well.

In terms of the language interoperability in PB12 PowerScript will be CLS-compliant, which means that PowerScript will be able to consume and extend any CLS-compliant resources produced by other .NET languages and produce PB .NET assemblies/Web Services as CLS-compliant component.

The non-CLS-compliant .NET resources will be considered to be consumed or extended case-by-case. For example if the resource only involves unsigned integer types that are not CLS-compliant types, PB will be able to support it.

On the other hand, since PowerScript has its own unique set of language features, many of them are not CLS-compliant, therefore, the overall functionality of PowerScript will go beyond CLS rules, and PB .NET target applications (Windows Forms, Web Forms, or WPF) don't have to be CLS-compliant, users can use any language feature to develop their .NET applications.

As we all know, System.Object type is the root type of all .NET types. In PB12, the type system of PowerScript will be enhanced. All PB primitive types will be equivalent to their corresponding .NET primitive types, and the functionality of the .NET Sytem.Enum type and the .NET System.Array type will be merged with that of the PB enum type and PB array type, respectively. The PB PowerObject type will also inherit from .NET System.Object type. Finally System. Object type will be the root type of all PB types as well.

In .NET, an interface defines a contract. A class that implements an interface must adhere to its contract. In PB12, users will be able to define their own interfaces, which can include methods, properties, events, and indexers. The new syntax is as follows:

global type ISub1 interface [from IBase1, IBase2]
//Functions
function string MyFunction(integer i)
subroutine MySub(string s)
//Properties
integer Myproperty1 [get, set]
integer Myproperty2 [set]
string Myproperty3[get]
//Events
event type integer MyEvent ( )
//Indexers
string this[integer i, integer j] [get, set]
end type

The PB object types Custom Class, Standard Class, Custom Visual, Standard Visual, Window, and Menu will be able to implement both user-defined PB interfaces and imported .NET interfaces.

Currently in PB, an unbounded array must be single-dimensional, which means the array-bound information of a multi-dimensional array must be specified at compile time. This limitation prevents users from declaring a multi-dimensional array without specifying the array-bound information and assigning another array to it at runtime, which is a pretty common scenario in .NET programming. For example, a Web Service may return a multi-dimensional array, whose size is unknown at compile time.

In PB12, a single-dimensional array will be enhanced so it can be dynamically created. For example, int arr[] which is an unbounded single-dimensional integer array.

At runtime, users can create a single-dimensional array as follow:

arr = create int[2 to 5]

which creates a single -dimensional integer array, with indexes of the one dimension being 2 to 5.