Results 1  10
of
26
ECC, an Extended Calculus of Constructions
, 1989
"... We present a higherorder 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 ..."
Abstract

Cited by 91 (4 self)
 Add to MetaCart
(Show Context)
We present a higherorder 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 prooftheoretic properties. An !\GammaSet (realizability) model is described to show how the essential properties of the calculus can be captured settheoretically.
Types for Modules
, 1998
"... 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 dy ..."
Abstract

Cited by 80 (13 self)
 Add to MetaCart
(Show Context)
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.
Program Specification and Data Refinement in Type Theory
 Mathematical Structures in Computer Science
, 1991
"... We develop a typetheoretic 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 c ..."
Abstract

Cited by 28 (10 self)
 Add to MetaCart
We develop a typetheoretic 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 higherorder 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...
Metalevel Building Blocks for Modular Systems
 ACM Transactions on Programming Languages and Systems
, 1994
"... 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 g ..."
Abstract

Cited by 21 (0 self)
 Add to MetaCart
(Show Context)
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.
Dependently Typed Records for Representing Mathematical Structure
 Theorem Proving in Higher Order Logics, TPHOLs 2000
, 2000
"... this paper appears in Theorem Proving in Higher Order Logics, TPHOLs 2000, c ..."
Abstract

Cited by 15 (0 self)
 Add to MetaCart
(Show Context)
this paper appears in Theorem Proving in Higher Order Logics, TPHOLs 2000, c
Structuring Specifications intheLarge and intheSmall: HigherOrder Functions, Dependent Types and Inheritance in SPECTRAL
 PROC. COLLOQ. ON COMBINING PARADIGMS FOR SOFTWARE DEVELOPMENT, JOINT CONF. ON THEORY AND PRACTICE OF SOFTWARE DEVELOPMENT (TAPSOFT
"... ..."
Sharing Code through Firstclass Environments
, 1996
"... 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 firstclass environments as a means to achieve that goal in a multiuser Scheme framework. We propose two new special ..."
Abstract

Cited by 10 (4 self)
 Add to MetaCart
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 firstclass environments as a means to achieve that goal in a multiuser 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.
A Reflective Model of Inheritance
, 1992
"... 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 nonstrict finite associations of labels to values. The constituent express ..."
Abstract

Cited by 8 (0 self)
 Add to MetaCart
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 nonstrict 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...
Dynamic Modules in HigherOrder Languages
 IN PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON COMPUTER LANGUAGES
, 1994
"... Providing programmers the ability to construct meaningful abstractions to help manage complexity is a serious language design issue. Many languages define a module system that can be used to specify distinct namespaces, and build userdefined data abstractions; however, few languages support dynamic ..."
Abstract

Cited by 7 (0 self)
 Add to MetaCart
Providing programmers the ability to construct meaningful abstractions to help manage complexity is a serious language design issue. Many languages define a module system that can be used to specify distinct namespaces, and build userdefined data abstractions; however, few languages support dynamic modules, i.e., modules which are true firstclass objects. In this paper, we define a module semantics for a dialect of Scheme called Rascal. Modules are defined in terms of reified environments, and are firstclass objects which may be dynamically created, freely assigned, used as arguments to procedures, etc.. If defined naively, however, implementing modules using environments can entail the capture of unwanted bindings, leading to potentially severe violations of lexical abstraction and locality. We address these concerns by giving users great flexibility to manipulate environments, and to constrain the extent and scope of the environment reification process. We argue that the techniqu...
The Scheme of Things
"... 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: Chan ..."
Abstract

Cited by 7 (0 self)
 Add to MetaCart
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 threeelement vectors, where one element (the first, say) is a unique token: (define queueuniquetoken (list 'queue)) (define (makequeue) (vector queueuniquetoken '() '())) (define (enqueue! q obj) (if (queue? q) (vectorset! q 1 (cons obj (vectorref q 1))) (error "expected a queue but found this instead" q))) (define (dequeue! q) ...) (define (queue? obj) (and (vector? obj) (= (vectorlength obj) 3) (eq? (vectorref obj 0) queueuniquetoken))) This particular choice of unique token even makes queues easily identifiable when displayed