| |
 |
|
The overall goal of the MCP series of formalisations is to produce a formalisation of a Component Pascal subset that supports generics. This is achieved in the final language in the MCP series, Imperative Mini Component Pascal with Generics (IMCPG). However, an intermediate step is required before adding support for generics to Component Pascal or IMCP. In order to support useful type parameterisation in Component Pascal or IMCP, there needs to be a way of expressing bounds (or constraints) on type parameters. The easiest way to do this is through interfaces. This is the approach taken in the Java and C# generics implementations. Therefore, we introduce Imperative Mini Component Pascal with Interfaces (IMCPI), which sits between the imperative (IMCP) and imperative-plus-generics (IMCPG) versions.
The lack of support for interfaces can be seen as a major deficiency in the official definition of Component Pascal. The Gardens Point Component Pascal compiler provides unofficial support for interfaces in order to facilitate interaction between Component Pascal code and .NET or Java code. However, being an unofficial extension this feature is somewhat sketchily documented. Therefore, the formalisation of IMCPI can be seen as serving a purpose independent from the overall goal of this project -- that is, it provides a suggested semantics (and implementation) for the Component Pascal interfaces extension.
Language features
Overview
IMCPI supports all of the constructs in IMCP, plus interface types. The syntax and semantics of interface types closely follow those supported by the current GPCP compiler. Syntactically, interface types are treated as record types with the additional modifier tag INTERFACE. A record type can extend a record supertype and implement zero or more interface types. Pointers to interface types are declared in the same way as pointers to record types.
Interfaces and restrictions on interface types
For the sake of simplicity, we introduce a few restrictions on interface types. Firstly, interface types cannot contain fields. Secondly, interface types can only extend a single superinterface. This prevents us from having to deal with the slightly tricky issue of defining a method type lookup function that recursively checks multiple supertypes.
We have also chosen the simple but primitive Java approach to interface implementation ambiguities, as opposed to the .NET approach. Java does not allow fully qualified implementations of interfaces; for example, if a class implements two interfaces that both define a method "void foo()", the class can only contain a single implementation "void foo()" that serves as the implementation of that method for both interfaces. Additionally, a class cannot implement different interfaces that define the same method with different return types.
.NET does not suffer from this problem, as interface implementations can be fully qualified. For example, in C#, if a class implements an interface IFoo, then the method "void foo()" could be implemented as follows:
public void IFoo.foo() { ... }
Nonetheless, we have chosen the Java approach for the following reasons. Firstly, it is hoped that this formalisation can be used as the basis for an implementation of interfaces and generics in the GPCP compiler. Because GPCP targets both the .NET CLR and the JVM, compatibility with Java bytecode is something that should be kept in mind. Fully qualified interface implementations targeting Java bytecode would require some inelegant name mangling techniques. Secondly, fully qualified interface implementations would introduce some complexities into the formalisation -- in the structure of the Methods table, for example. An extension of IMCPI with support for fully qualified interface implementations may be an interesting exercise for further research, however.
Another aspect of IMCPI that may be open to debate is the ability to declare variables of interface value type. An examination of the language definition reveals such variables to be more or less useless, since they contain no fields and you cannot invoke methods on them. However, they pose no problems as far as type-checking is concerned; explicitly disallowing variables of interface value type would introduce unnecessary complexity.
Interfaces and ABSTRACT methods
Note that although we introduce an ABSTRACT modifier tag for method declarations, this only applies to methods defined for interface types, as we do not support ABSTRACT record types. Syntactically, method bodies (including local variable declarations, body statements, and return expression) are factored out into a separate syntactic category, "pbody", which becomes an optional syntactic element in method declarations. The "pbody" element does not need to be present in ABSTRACT methods (i.e. methods defined for interface types).
|
