DOCSLIB.ORG

CLOS Generic Function and Method Parameters

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CLOS Generic Function and Method Parameters Generic Function Parameter and Metho d Parameter Metaob jects: A Prop osed Enhancement to the CLOS Metaob ject Proto col Eric L. Peterson Arti cial Intelligence Technologies Center MITRE Corp oration 1820 Dolley Madison Blvd. McLean, VA 22102-3481 e-mail: [email protected] URL: http://www.cs.umd.edu/users/ericp phone: (703) 883-6116 FAX: (703) 883-6435 April 25, 1996 Abstract Common Lisp's Metaob ject Proto col de nes classes of ob jects whichembody various asp ects of the ob ject oriented programming environment. Current such metaob jects represent classes, slots, generic functions, metho ds, as well as other ob ject oriented entities. Not currently included, however, are ob jects that represent generic function and metho d parameters. This pap er rst gives class de nitions declaring the b ehavior of these prop osed parameter metaob jects and then pro ceeds to argue for for their inclusion in the exp ected addition of the Metaob jects Proto col to the ANSI Common Lisp Standard. 1 Intro duction The Common Lisp Ob ject System's (CLOS) Metaob ject Proto col (MOP), as put forth in The Art of the Metaobject Protocol (AMOP) [2], provides metaob jects representing many asp ects of the state of the 1 2 dynamic ob ject oriented program. It is widely embraced as a de facto standard. Perhaps the largest asp ect of the ob ject oriented program still untamed by the MOP is the rendering of the actual metho d co de as a network of ob jects. This pap er, however, is concerned with the taming of a simpler asp ect. 2 The Prop osal This pap er argues for the incorp oration of ve new instantiable metaob ject classes as well as their ancestors into the CLOS MOP prior to the MOP's incorp oration into the Common Lisp ANSI standard. These metaob jects represent generic function (GF) and metho d parameters. Their instantiable classes are as follows: standard-generic-function-parameter standard-method-parameter standard-optional-parameter standard-rest-parameter 0 Eric Peterson is a memb er of the Machine Translation Group at the Arti cial Intelligence Technologies Center at the MITRE Corp oration. Thanks go to Lawrence Mayka and David Tereb essy for review comments and to Lawrence for the CLIM example/argument. 1 The term MOP, in this pap er will b e understo o d to mean the AMOP MOP. 2 Slight di erences in metaob ject proto cols exist b etween Common Lisp implementations. 1 standard-keyword-parameter The rst two parameters represent the required parameters from generic function and metho d lambda lists resp ectively. The remaining parameter metaob jects represent non-required parameter information 3 and are to b e used in either generic function or metho d lamb da lists containing non-required parameters. Please see Figure 1 for the de nitions of these classes and for the descriptive information found in their CLOS do cumentation strings. This prop osed family of metaob jects would require a new defmethod -like macro to allow for the input of metadata b eyond what is found in a standard defmethod macro. See Figure 2 for an example use of such a macro. The conventional defmethod macro would still b e available , but would serve to load conventional parameter information into metaob jects of the kind describ ed in this pap er. It would still serve ordinary ob ject oriented programming needs in the traditional fashion. The new macro would b e for those who wish to do cument their parameters in a run-time retrievable fashion, as well as for those who which to asso ciate additional information with those parameters. To some, it may app ear overly verb ose, yet it should b e noted that it is no more verb ose than the CLOS slot sp eci cations within the defclass macro. In b oth cases, terse representations would not allow for seamless addition of non-standard attributes as is done by the sub classing of slot de nition metaob jects. Both standard-generic-function and standard-method ,two existing MOP metaob jects, would receive 4 a new slot called parameters . The lists would not contain the traditional &optional , &rest , &key , and &al low-other-keys delimiter tokens. None would b e needed, b ecause the typ es of the metaob jects would b e immediately determinable. An additional sibling slot to parameters would b e called al low-other-keys and would take the place of the lamb da list token of the same name and would serve as a b o olean indication as to whether other keys would b e allowed. The following ve new GF's would b e added to the MOP: generic-function-parameter-class method-parameter-class optional-parameter-class rest-parameter-class keyword-parameter-class They would b e analogous in purp ose to the e ective-slot-de nition-class GF. They would allow the CLOS user/extender to communicate the presence of parameter metaob ject sub classes to the CLOS/MOP environment.f It may b e argued that supplied-p do es not b elong in a parameter metaob jects b ecause it has nothing to do with the sp eci cation of the GF/metho d interface. Although it is clearly a piece of utility information for the b ene t of the metho d(s)' lexical environment, this prop osed change, like current lamb da lists, makes no distinction b etween interfacespeci cation , and utility information. It is prop osed that any information that is logicall y asso ciated with such a parameter, is not only welcome, but encouraged to b ecome part of a parameter metaob ject. &aux parameters would simply b e treated as if macro expanded into let expressions, as is presently 5 done. They would have no metaob jects. Caching of parameter metadata would, as allowed by the MOP, b e p ermitted. Therefore, implemen- tations would b e free to create and cache conventional lamb da lists in GF and metho d metaob jects. Implementations could thus obtain runtime p erformance identical to their present implementation s for generic dispatch not involvin g additional parameter metadata from user enhanced parameter metaob- jects. 3 The term non-required is used to refer to &optional , &rest , and &keyword parameters. The term optional would, of course, have b een ambiguous. 4 Both the use of the term slot and the use of class de nitions with slots are for exp ository convenience. Precisely sp eaking, such b ehavior could b e implemented without the use of slots. Assume that the b ehavior is as if de ned as shown. 5 Future work alluded to later in this pap er will require metaob jects for program variables in order to house variable related metadata. This suggests the p ossibility that metaob jects for auxiliary variables would b e needed as well. 2 (defclass parameter (clos:metaobject) ((parameter-name :type symbol :documentation "The name of a lambda list parameter" :accessor parameter-name) (parameter-documentation :type string :documentation "User supplied documentation of parameter" :accessor parameter-documentation :initarg :documentation)) (:documentation "Information pertaining to a given lambda list parameter")) (defclass standard-generic-function-parameter (parameter)() (:documentation "Information pertaining to a generic function parameter")) (defclass standard-method-parameter (parameter) ((method-parameter-specializer :type (or symbol list) :documentation "Parameter specializer for generic dispatch" :accessor method-parameter-specializer :initarg :specializer :initform t)) (:documentation "Information pertaining to a given method parameter")) (defclass optional-parameter (parameter) ((optional-parameter-default :documentation "Default value for &optional parameters" :accessor optional-parameter-default :initarg :default :initform nil) (optional-parameter-supplied-p :documentation "An indication of whether the calling function supplied the argument" :accessor optional-parameter-supplied-p :initarg :supplied-p :initform nil) (optional-parameter-type :type (or symbol list) :documentation "Non-specializing type information" :accessor optional-parameter-type :initarg :type :initform t)) (:documentation "Information pertaining to a given &optional parameter")) (defclass standard-optional-parameter (optional-parameter) () (:documentation "Information pertaining to a given parameter")) (defclass standard-rest-parameter (parameter) () (:documentation "Information pertaining to a given &rest parameter")) (defclass standard-keyword-parameter (optional-parameter) ((keyword-parameter-keyword :documentation "For when the keyword is different from the parameter name" :accessor :keyword-parameter-keyword :initarg :keyword)) (:documentation "Information pertaining to a given &key parameter")) Figure 1: Generic function and metho d parameter metaob jects would b ehave as if sp eci ed by these class de nitions. Metaob ject classes whose names b egin with standard are instantiable. 3 (defmethod+ foo ((bar-param :specializer float :documentation "bar parameter documentation" :unit-of-measure :kilopascals) &optional (baz-param :type float :default bar-default-value :supplied-p bar-supplied-p-value :documentation "bar documentation" :unit-of-measure :kilopascals) &key (blat-param :type float :keyword :blat-actual-keyword :default blat-default-value :supplied-p blat-supplied-p-value :documentation "blat documentation" :unit-of-measure :joules)) ...) Figure 2: An example use of the prop osed defmethod -like macro. Parameter attributes are sp eci ed in CLOS defclass slot de nition fashion. CLOS users not needing or wishing this much representational p ower would simply use defmethod in the traditional manner. 3 Motivations 3.1 Adding Parameter Metadata 3.1.1 Parameter Do cumentation Perhaps the most commonly felt desire for more parameter representational p ower is the desire to b e able to add runtime accessible do cumentation to GF and metho d parameters. Although such information could b e placed somewhere in a mo di cation of the existing lamb da list, if the parameters were presently implemented as ob jects, these ob jects would b e a convenient place for the parameter do cumentation to reside.
Load more

Recommended publications
  • Metaobject Protocols: Why We Want Them and What Else They Can Do
    Metaobject protocols: Why we want them and what else they can do Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow Published in A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 101 ¾ 118. The MIT Press, Cambridge, MA, 1993. © Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. Metaob ject Proto cols WhyWeWant Them and What Else They Can Do App ears in Object OrientedProgramming: The CLOS Perspective c Copyright 1993 MIT Press Gregor Kiczales, J. Michael Ashley, Luis Ro driguez, Amin Vahdat and Daniel G. Bobrow Original ly conceivedasaneat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protcols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static paral lelization of Scheme programs. Intro duction The CLOS Metaob ject Proto col MOP was motivated by the tension b etween, what at the time, seemed liketwo con icting desires. The rst was to have a relatively small but p owerful language for doing ob ject-oriented programming in Lisp. The second was to satisfy what seemed to b e a large numb er of user demands, including: compatibility with previous languages, p erformance compara- ble to or b etter than previous implementations and extensibility to allow further exp erimentation with ob ject-oriented concepts see Chapter 2 for examples of directions in which ob ject-oriented techniques might b e pushed.
    [Show full text]
  • Chapter 2 Basics of Scanning And
    Chapter 2 Basics of Scanning and Conventional Programming in Java In this chapter, we will introduce you to an initial set of Java features, the equivalent of which you should have seen in your CS-1 class; the separation of problem, representation, algorithm and program – four concepts you have probably seen in your CS-1 class; style rules with which you are probably familiar, and scanning - a general class of problems we see in both computer science and other fields. Each chapter is associated with an animating recorded PowerPoint presentation and a YouTube video created from the presentation. It is meant to be a transcript of the associated presentation that contains little graphics and thus can be read even on a small device. You should refer to the associated material if you feel the need for a different instruction medium. Also associated with each chapter is hyperlinked code examples presented here. References to previously presented code modules are links that can be traversed to remind you of the details. The resources for this chapter are: PowerPoint Presentation YouTube Video Code Examples Algorithms and Representation Four concepts we explicitly or implicitly encounter while programming are problems, representations, algorithms and programs. Programs, of course, are instructions executed by the computer. Problems are what we try to solve when we write programs. Usually we do not go directly from problems to programs. Two intermediate steps are creating algorithms and identifying representations. Algorithms are sequences of steps to solve problems. So are programs. Thus, all programs are algorithms but the reverse is not true.
    [Show full text]
  • Towards Practical Runtime Type Instantiation
    Towards Practical Runtime Type Instantiation Karl Naden Carnegie Mellon University [email protected] Abstract 2. Dispatch Problem Statement Symmetric multiple dispatch, generic functions, and variant type In contrast with traditional dynamic dispatch, the runtime of a lan- parameters are powerful language features that have been shown guage with multiple dispatch cannot necessarily use any static in- to aid in modular and extensible library design. However, when formation about the call site provided by the typechecker. It must symmetric dispatch is applied to generic functions, type parameters check if there exists a more specific function declaration than the may have to be instantiated as a part of dispatch. Adding variant one statically chosen that has the same name and is applicable to generics increases the complexity of type instantiation, potentially the runtime types of the provided arguments. The process for deter- making it prohibitively expensive. We present a syntactic restriction mining when a function declaration is more specific than another is on generic functions and an algorithm designed and implemented for laid out in [4]. A fully instantiated function declaration is applicable the Fortress programming language that simplifies the computation if the runtime types of the arguments are subtypes of the declared required at runtime when these features are combined. parameter types. To show applicability for a generic function we need to find an instantiation that witnesses the applicability and the type safety of the function call so that it can be used by the code. Formally, given 1. Introduction 1. a function signature f X <: τX (y : τy): τr, J K Symmetric multiple dispatch brings with it several benefits for 2.
    [Show full text]
  • Common Lisp Object System Specification 3. Metaobject Protocol
    Common Lisp Object System Specification 3. Metaobject Protocol This document was written by Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Contributors to this document include Patrick Dussud, Kenneth Kahn, Jim Kempf, Larry Masinter, Mark Stefik, Daniel L. Weinreb, and Jon L White. CONTENTS CONTENTS ................................................... ............ 3–2 Status of Document ................................................... ........... 3–5 Terminology ................................................... ................ 3–6 Introduction ................................................... ................ 3–7 Class Organization in the CLOS Kernel ............................................... 3–9 The Classes in the CLOS Kernel ................................................... 3–10 standard-class ................................................... ............ 3–11 forward-referenced-class ................................................... ..... 3–11 built-in-class ................................................... ............. 3–11 structure-class ................................................... ............ 3–12 funcallable-standard-class ................................................... .... 3–12 standard-slot-description ................................................... .... 3–12 standard-class-slot-description ................................................... 3–12 standard-method ................................................... .......... 3–12
    [Show full text]
  • Lecture 2: Variables and Primitive Data Types
    Lecture 2: Variables and Primitive Data Types MIT-AITI Kenya 2005 1 In this lecture, you will learn… • What a variable is – Types of variables – Naming of variables – Variable assignment • What a primitive data type is • Other data types (ex. String) MIT-Africa Internet Technology Initiative 2 ©2005 What is a Variable? • In basic algebra, variables are symbols that can represent values in formulas. • For example the variable x in the formula f(x)=x2+2 can represent any number value. • Similarly, variables in computer program are symbols for arbitrary data. MIT-Africa Internet Technology Initiative 3 ©2005 A Variable Analogy • Think of variables as an empty box that you can put values in. • We can label the box with a name like “Box X” and re-use it many times. • Can perform tasks on the box without caring about what’s inside: – “Move Box X to Shelf A” – “Put item Z in box” – “Open Box X” – “Remove contents from Box X” MIT-Africa Internet Technology Initiative 4 ©2005 Variables Types in Java • Variables in Java have a type. • The type defines what kinds of values a variable is allowed to store. • Think of a variable’s type as the size or shape of the empty box. • The variable x in f(x)=x2+2 is implicitly a number. • If x is a symbol representing the word “Fish”, the formula doesn’t make sense. MIT-Africa Internet Technology Initiative 5 ©2005 Java Types • Integer Types: – int: Most numbers you’ll deal with. – long: Big integers; science, finance, computing. – short: Small integers.
    [Show full text]
  • Kind of Quantity’
    NIST Technical Note 2034 Defning ‘kind of quantity’ David Flater This publication is available free of charge from: https://doi.org/10.6028/NIST.TN.2034 NIST Technical Note 2034 Defning ‘kind of quantity’ David Flater Software and Systems Division Information Technology Laboratory This publication is available free of charge from: https://doi.org/10.6028/NIST.TN.2034 February 2019 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Undersecretary of Commerce for Standards and Technology Certain commercial entities, equipment, or materials may be identifed in this document in order to describe an experimental procedure or concept adequately. Such identifcation is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. National Institute of Standards and Technology Technical Note 2034 Natl. Inst. Stand. Technol. Tech. Note 2034, 7 pages (February 2019) CODEN: NTNOEF This publication is available free of charge from: https://doi.org/10.6028/NIST.TN.2034 NIST Technical Note 2034 1 Defning ‘kind of quantity’ David Flater 2019-02-06 This publication is available free of charge from: https://doi.org/10.6028/NIST.TN.2034 Abstract The defnition of ‘kind of quantity’ given in the International Vocabulary of Metrology (VIM), 3rd edition, does not cover the historical meaning of the term as it is most commonly used in metrology. Most of its historical meaning has been merged into ‘quantity,’ which is polysemic across two layers of abstraction.
    [Show full text]
  • Balancing the Eulisp Metaobject Protocol
    Balancing the EuLisp Metaob ject Proto col x y x z Harry Bretthauer and Harley Davis and Jurgen Kopp and Keith Playford x German National Research Center for Computer Science GMD PO Box W Sankt Augustin FRG y ILOG SA avenue Gallieni Gentilly France z Department of Mathematical Sciences University of Bath Bath BA AY UK techniques which can b e used to solve them Op en questions Abstract and unsolved problems are presented to direct future work The challenge for the metaob ject proto col designer is to bal One of the main problems is to nd a b etter balance ance the conicting demands of eciency simplicity and b etween expressiveness and ease of use on the one hand extensibili ty It is imp ossible to know all desired extensions and eciency on the other in advance some of them will require greater functionality Since the authors of this pap er and other memb ers while others require greater eciency In addition the pro of the EuLisp committee have b een engaged in the design to col itself must b e suciently simple that it can b e fully and implementation of an ob ject system with a metaob ject do cumented and understo o d by those who need to use it proto col for EuLisp Padget and Nuyens intended This pap er presents a metaob ject proto col for EuLisp to correct some of the p erceived aws in CLOS to sim which provides expressiveness by a multileveled proto col plify it without losing any of its p ower and to provide the and achieves eciency by static semantics for predened means to more easily implement it eciently The current metaob
    [Show full text]
  • Subtyping, Declaratively an Exercise in Mixed Induction and Coinduction
    Subtyping, Declaratively An Exercise in Mixed Induction and Coinduction Nils Anders Danielsson and Thorsten Altenkirch University of Nottingham Abstract. It is natural to present subtyping for recursive types coin- ductively. However, Gapeyev, Levin and Pierce have noted that there is a problem with coinductive definitions of non-trivial transitive inference systems: they cannot be \declarative"|as opposed to \algorithmic" or syntax-directed|because coinductive inference systems with an explicit rule of transitivity are trivial. We propose a solution to this problem. By using mixed induction and coinduction we define an inference system for subtyping which combines the advantages of coinduction with the convenience of an explicit rule of transitivity. The definition uses coinduction for the structural rules, and induction for the rule of transitivity. We also discuss under what condi- tions this technique can be used when defining other inference systems. The developments presented in the paper have been mechanised using Agda, a dependently typed programming language and proof assistant. 1 Introduction Coinduction and corecursion are useful techniques for defining and reasoning about things which are potentially infinite, including streams and other (poten- tially) infinite data types (Coquand 1994; Gim´enez1996; Turner 2004), process congruences (Milner 1990), congruences for functional programs (Gordon 1999), closures (Milner and Tofte 1991), semantics for divergence of programs (Cousot and Cousot 1992; Hughes and Moran 1995; Leroy and Grall 2009; Nakata and Uustalu 2009), and subtyping relations for recursive types (Brandt and Henglein 1998; Gapeyev et al. 2002). However, the use of coinduction can lead to values which are \too infinite”. For instance, a non-trivial binary relation defined as a coinductive inference sys- tem cannot include the rule of transitivity, because a coinductive reading of transitivity would imply that every element is related to every other (to see this, build an infinite derivation consisting solely of uses of transitivity).
    [Show full text]
  • Guide for the Use of the International System of Units (SI)
    Guide for the Use of the International System of Units (SI) m kg s cd SI mol K A NIST Special Publication 811 2008 Edition Ambler Thompson and Barry N. Taylor NIST Special Publication 811 2008 Edition Guide for the Use of the International System of Units (SI) Ambler Thompson Technology Services and Barry N. Taylor Physics Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 (Supersedes NIST Special Publication 811, 1995 Edition, April 1995) March 2008 U.S. Department of Commerce Carlos M. Gutierrez, Secretary National Institute of Standards and Technology James M. Turner, Acting Director National Institute of Standards and Technology Special Publication 811, 2008 Edition (Supersedes NIST Special Publication 811, April 1995 Edition) Natl. Inst. Stand. Technol. Spec. Publ. 811, 2008 Ed., 85 pages (March 2008; 2nd printing November 2008) CODEN: NSPUE3 Note on 2nd printing: This 2nd printing dated November 2008 of NIST SP811 corrects a number of minor typographical errors present in the 1st printing dated March 2008. Guide for the Use of the International System of Units (SI) Preface The International System of Units, universally abbreviated SI (from the French Le Système International d’Unités), is the modern metric system of measurement. Long the dominant measurement system used in science, the SI is becoming the dominant measurement system used in international commerce. The Omnibus Trade and Competitiveness Act of August 1988 [Public Law (PL) 100-418] changed the name of the National Bureau of Standards (NBS) to the National Institute of Standards and Technology (NIST) and gave to NIST the added task of helping U.S.
    [Show full text]
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications
    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
    [Show full text]
  • OOD and C++ Section 5: Templates
    Templates - Generic Programming Decide which algorithms you want: parameterize them so that they work for OOD and C++ a wide-range of types & data structures Section 5: Templates Templates in C++ support generic progarmming Templates provide: •simple way to represent general concepts •simple way to combine concepts Use ‘data-types’ as parameters at compilation Advantage: • more general ‘generic code’ • reuse same code for different data types • less bugs - only implement/debug one piece of code • no overhead on run-time efficiency compared to data specific code Use of Templates Templates in C++ Make the definition of your class as broad as possible! template class declaration: mytemplate.hh template <class DataC> class mytemplate { public: Widely used for container classes: mytemplate(); • Storage independent of data type void function(); • C++ Standard Template Library (Arrays,Lists,…..) protected: int protected_function(); Encapsulation: private: Hide a sophisticated implementation behind a simple double private_data; interface }; template <class DataC>: • specifies a template is being declared • type parameter ‘DataC’ (generic class) will be used • DataC can be any type name: class, built in type, typedef • DataC must contain data/member functions which are used in template implementation. Example - Generic Array Example - Generic Array (cont’d) simple_array.hh template<class DataC> class simple_array { private: #include “simple_array.hh” int size; DataC *array; #include “string.hh” public: void myprogram(){ simple_array(int s); simple_array<int> intarray(100); ~simple_array(); simple_array<double> doublearray(200); DataC& operator[](int i); simple_array<StringC> stringarray(500); }; for (int i(0); i<100; i++) template<class DataC> intarray[i] = i*10; simple_array<DataC>::simple_array(int s) : size(s) { array = new DataC[size]; } // & the rest….
    [Show full text]
  • PDF (Dissertation.Pdf)
    Kind Theory Thesis by Joseph R. Kiniry In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy California Institute of Technology Pasadena, California 2002 (Defended 10 May 2002) ii © 2002 Joseph R. Kiniry All Rights Reserved iii Preface This thesis describes a theory for representing, manipulating, and reasoning about structured pieces of knowledge in open collaborative systems. The theory's design is motivated by both its general model as well as its target user commu- nity. Its model is structured information, with emphasis on classification, relative structure, equivalence, and interpretation. Its user community is meant to be non-mathematicians and non-computer scientists that might use the theory via computational tool support once inte- grated with modern design and development tools. This thesis discusses a new logic called kind theory that meets these challenges. The core of the work is based in logic, type theory, and universal algebras. The theory is shown to be efficiently implementable, and several parts of a full realization have already been constructed and are reviewed. Additionally, several software engineering concepts, tools, and technologies have been con- structed that take advantage of this theoretical framework. These constructs are discussed as well, from the perspectives of general software engineering and applied formal methods. iv Acknowledgements I am grateful to my initial primary adviser, Prof. K. Mani Chandy, for bringing me to Caltech and his willingness to let me explore many unfamiliar research fields of my own choosing. I am also appreciative of my second adviser, Prof. Jason Hickey, for his support, encouragement, feedback, and patience through the later years of my work.
    [Show full text]