Type Checking Parametrised Programs and Specifications in ASL+FPC

ASL+ [SST92] is a kernel specification language with higherorder parametrisation for programs and specifications, based on a dependently typed λ-calculus. ASL+ has an institution-independent semantics, which leaves the underlying programming language and specification logic unspecified. To complete the definition, and in particular, to study the type checking problem for ASL+, the language ASL+FPC was conceived. It is a modified version of ASL+ for FPC, and institution based on the paradigmatic programming calculus FPC. The institution FPC is notable for including sharing equations inside signatures, reminiscent of so-called manifest types or translucent sums in type systems for programming language modules [Ler94,HL94]. This allows type equalities to be propagated when composing modules. This paper introduces FPC and ASL+FPC and their type checking systems. 1 Program Development with Institutions A simple setup for program development with institutions [GB92] is to consider programs to be syntactic expressions denoting models from an institution I, and specifications to be syntactic expressions denoting classes of models. More elaborate views are certainly possible (e.g., programming languages considered as institutions whose satisfaction relation is a function), but perhaps unnecessary. One issue that must be resolved is the relationship between identifiers in the syntax, and their semantic equivalents. In particular, the possibility of aliasing, or as it is known in the context of modular programming, sharing, should be considered. While a real language may already include an understanding of sharing, the usual institutional semantics of a specification language such as ASL in equational logic EQ or first-order logic FOL does not, simply because there is no way to specify sharing in algebraic signatures. For example, given Σ =def sig sorts s, t opns c : s, d : t end the equation “c=d” is ill-typed because c and d have distinct sorts; so this equation is not in Sen(Σ). However, flexible ways of parameter passing can mean that the same sort can be referred to via several different identifiers, so there are occasions when this equation should be considered well-typed. The classical example is the “diamond-import” situation [Mac86], illustrated by the Standard ML (SML) functor heading: functor F (structure S1 : sig type intset ... end structure S2 : sig type intset ... end sharing type S1.intset = S2.intset) = ... The parametrised program F has two parameter modules S1 and S2, but requires that any actual parameters have identical implementations of the intset type. This means that when type checking the body of the functor, the given type equation can be assumed. In the algebraic case, sometimes we may want to suppose that sorts s and t denote the same set, so c = d is type-correct. This issue may seem simple, but propagating type equalities properly lies at the heart of type-theoretic explanations of programming language module systems, an issue which researchers have worked on for well over a decade (contributions include [HMM90,HL94,Ler95,Ler96,Jon96,Rus99]). The design of a module type system is affected both by the type system of the underlying language, and by the flexibility of the module system: higher-order, first-class and recursive modules have all been considered. The work reported here is a first attempt to design a type system for a language which has higher-order parametrisation of both programs and specifications. With an institution-based semantics, we have two ways to go: Ignore sharing: e.g., by extending the satisfaction relation |= to be three valued, so that A |= φ ∈ { true, false,wrong }. Then Sen(Σ) is extended to contain all formulae which could possibly have a denotation. So now c = d ∈ Sen(Σ), but if Ac 6= Ad, then (A |= c = d) = wrong. This is a bit like dynamic type checking in programming languages, and similarly unattractive: nonsensical sentences accidentally become meaningful. Handle sharing: e.g., by adding information to signatures, to maintain the idea of static type checking. Then Sen(Σ) consists only of formulae which have a denotation in the semantics, as usual. This approach seems desirable when we have languages that can be statically type-checked. Following the second choice, there are two ways of handling sharing: External sharing: resolve sharing outwith the institutional notion of signature. For example, we could maintain a map from “external identifiers” to “internal names,” the latter being names in an algebraic signature. This is (a bit) like the 1990 SML semantics, and was suggested in the algebraic semantics sketched for Extended ML in [ST86]. Internal sharing: make sharing part of the notion of signatures in the institution somehow. For example, to handle type sharing, signatures could be equipped with an equivalence relation on sorts. The advantage of external sharing is keeping our familiar institutions. The considerable disadvantage is that we break the institution-independent framework: for example, specification building operators of ASL must be lifted to operate on the “external” part of algebraic signatures, and general results must be reproved. (Nonetheless, this route has been followed for the semantics of CASL by introducing institutions with symbols [Mos99].) The internal sharing alternative means that we must modify the institution. But after that, we can apply the general institution-independent framework. We treat signatures as static typing environments which contain all that’s needed to type-check terms and formulae; Sen(Σ) is exactly the set of well-typed formulae in the abstract syntax over Σ. This is the route that we follow for ASL+FPC . ASL+FPC is an attempt to give a complete but small definition of a formal development framework. We start from the fixed-point calculus FPC, which is a prototypical expression language for higher-order functional programming. Then we define syntax and semantics for a programming language, specification language and logic, and fit these into a λ-calculus used for structuring, based on ASL+ [SST92,Asp95b]. The syntax and semantics of each part are put together in the same way: