We present a higher-order calculus ECC which can be seen as an extension of the calculus of constructions [CH88] by adding strong sum types and a fully cumulative type hierarchy. ECC turns out to be rather expressive so that mathematical theories can be abstractly described and abstract mathematics may be adequately formalized. It is shown that ECC is strongly normalizing and has other nice proof-theoretic properties. An !\GammaSet (realizability) model is described to show how the essential properties of the calculus can be captured set-theoretically.

The programming language Standard ML is an amalgam of two, largely orthogonal, languages. The Core language expresses details of algorithms and data structures. The Modules language expresses the modular architecture of a software system. Both languages are statically typed, with their static and dynamic semantics specified by a formal definition.

We develop a type-theoretic approach to program specification and data refinement and show that a type theory with a strong logical power and nice structural mechanisms provides an adequate formalism for modular development of programs and specifications. Specification of abstract data types is considered and a notion of abstract implementation between specifications is defined in the type theory and studied as a basis for correct and modular development of programs by stepwise refinement. The higher-order structural mechanisms in the type theory provide useful and flexible tools (specification operations and parameterized specifications) for modular design and structured specification. Refinement maps (programs and design decisions) and proofs of implementation correctness can be developed by means of the existing proof development systems based on type theories. 1 Introduction Program specification and modular program development by stepwise refinement has been an interes...

this article, we propose a treatment of environments and the mechanism by which they are reified and manipulated, that addresses these concerns. The language described below (Rascal) permits environments to be reified into data structures, and data structures to be reflected into environments, but gives users great flexibility to constrain the extent and scope of these processes. We argue that the techniques and operators developed define a cohesive basis for building largescale modular systems using reflective programming techniques.

this paper appears in Theorem Proving in Higher Order Logics, TPHOLs 2000, c

Abstract not found

ions are introduced using notation; conditionals are written using !; application is expressed by juxtaposition of the function being applied with its arguments. Recursion is expressed using letrec . 3.1 Records Records are non-strict finite associations of labels to values. The constituent expressions in a record are evaluated relative to the record's evaluation environment. The value of a record field can be retrieved using the "." operator: if r is a record, then evaluating r:x returns the binding value of x as defined in r. We provide one other operation over records. Let r 1 and r 2 be two records and let Dom(r) be the set of names defined within record r. The join or composition of r 1 and r 2 (written (ffl r 1 r 2 )) is now defined as follows: (ffl r 1 r 2 ):x = ae r 2 :x if x 2 Dom(r2) r 1 :x otherwise 3 Besides these basic syntactic forms, we introduce various syntactic extensions (or abbreviations) throughout the paper; these extensions are best thought of as macros th...

Nowadays the Net is one of the most obvious driving forces. Yet, to consider it as one global store through which values and code may be shared is still immature. This paper suggests first-class environments as a means to achieve that goal in a multi-user Scheme framework. We propose two new special forms with a simple semantics. Our model allows precise control over environments (including extensible environments) and does not require (but does not prevent) reflective operations. 1 Motivation Millions of users now dream of means through which they may share programs and/or data. Data are becoming more and more complex; they are no longer made of simple, atomic, flat values such as numbers or characters but now mundanely incorporate pointers, as exhibited by the increasing number of WWW pages full of references towards remote pieces of information. Other data are only acquired after long computations and are better shared rather than recomputed. Of course, data may be stored in share...

dentally pass a queue to an operator like length that expects a list, I would like to see a meaningful diagnostic message. 3. Disjointness: One would like to be able write case analyses that discriminate between queues and members of other Scheme types. The first of these is easily addressed: Change the representation of queues so that they are marked as being queues. For example, queues could be represented as three-element vectors, where one element (the first, say) is a unique token: (define queue-unique-token (list 'queue)) (define (make-queue) (vector queue-unique-token '() '())) (define (enqueue! q obj) (if (queue? q) (vector-set! q 1 (cons obj (vector-ref q 1))) (error "expected a queue but found this instead" q))) (define (dequeue! q) ...) (define (queue? obj) (and (vector? obj) (= (vector-length obj) 3) (eq? (vector-ref obj 0) queue-unique-token))) This particular choice of unique token even makes queues easily identifiable when displayed

This paper gives a formal description of -- at least a part of -- the type system of Aldor, the extension language of the computer algebra system AXIOM. In the process of doing this a critique of the design of the system emerges.