DOCSLIB.ORG

A Language for Generic Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Language for Generic Programming A LANGUAGE FOR GENERIC PROGRAMMING Jeremy G. Siek Submitted to the faculty of the University Graduate School in partial fulfillment of the requirements for the degree Doctor of Philosophy in the Department of Computer Science Indiana University August, 2005 Accepted by the Graduate Faculty, Indiana University, in partial fulfillment of the require- ments for the degree of Doctor of Philosophy. Andrew Lumsdaine, Ph.D. R. Kent Dybvig, Ph.D. Daniel P. Friedman, Ph.D. Steven D. Johnson, Ph.D. Amr Sabry, Ph.D. August, 2005 ii Copyright 2005 Jeremy G. Siek All rights reserved iii This dissertation is dedicated to my wonderful wife Katie who was next to me every step of this journey. iv Acknowledgements First and foremost I thank my parents for all their love and for teaching me to enjoy learn- ing. I especially thank my wife Katie for her support and understanding through this long and sometimes stressful process. I also thank Katie for insisting on good error messages for ! My advisor, Andrew Lumsdaine, deserves many thanks for his support and guidance G and for keeping the faith as I undertook this long journey away from scientific computing and into the field of programming languages. I thank my thesis committee: R. Kent Dybvig, Daniel P. Friedman, Steven D. Johnson, and Amr Sabry for their advice and encourage- ment. A special thanks goes to Ronald Garcia, Christopher Mueller, and Douglas Gregor for carefully editing and catching the many many times when I accidentally skipped over the important stuff. Thanks to Jaakko and Jeremiah for hours of stimulating discussions and arguments concerning separate compilation and concept-based overloading. Thanks to David Abrahams for countless hours spent debating the merits of one design over another while jogging through the hinterlands of Norway. Thanks to Alexander Stepanov and David Musser for getting all this started, and thank you for the encouragement over the years. Thanks to Matthew Austern, his book Generic Programming in the STL was both an inspi- ration and an invaluable reference. Thanks to Beman Dawes and everyone involved with the Boost libraries. The collective experience from Boost was vital in the creation of this thesis. Thanks to Vincent Cremet and Martin Odersky for answering questions about Scala and virtual types. v Abstract The past decade of software library construction has demonstrated that the discipline of generic programming is an effective approach to the design and implementation of large- scale software libraries. At the heart of generic programming is a semi-formal interface specification language for generic components. Many programming languages have fea- tures for describing interfaces, but none of them match the generic programming specifi- cation language, and none are as suitable for specifying generic components. This lack of language support impedes the current practice of generic programming. In this dissertation I present and evaluate the design of a new programming language, named (for generic), G that integrates the generic programming specification language with the type system and features of a full programming language. The design of is based on my experiences, G and those of colleagues, in the construction of generic libraries over the past decade. The design space for programming languages is large, thus this experience is vital in guiding choices among the many tradeoffs. The design of emphasizes modularity because generic G programming is inherently about composing separately developed components. In this dis- sertation I demonstrate that the design is implementable by constructing a compiler for G (translating to C++) and show the suitability of for generic programming with prototypes G of the Standard Template Library and the Boost Graph Library in . I formalize the essential G features of in a small language and prove type soundness. G vi Contents Chapter 1. Introduction 1 1.1. Lowering the cost of developing generic components 5 1.2. Lowering the cost of reusing generic components 7 1.3. : a language for generic programming 9 G 1.4. Related work in programming language research 10 1.5. Claims and evaluation 11 1.6. Road map 12 Chapter 2. Generic programming and the STL 13 2.1. An example of generic programming 15 2.2. Survey of generic programming in the STL 21 2.3. Relation to other methodologies 49 2.4. Summary 54 Chapter 3. The language design space for generics 55 3.1. Preliminary design choices 55 3.2. Subtyping versus type parameterization 59 3.3. Parametric versus macro-like type parameterization 65 3.4. Concepts: organizing type requirements 73 3.5. Nominal versus structural conformance 83 3.6. Constrained polymorphism 85 vii 3.7. Summary 89 Chapter 4. The design of 90 G 4.1. Generic functions 92 4.2. Concepts 95 4.3. Models 96 4.4. Modules 98 4.5. Type equality 98 4.6. Function application and implicit instantiation 101 4.7. Function overloading and concept-based overloading 108 4.8. Generic user-defined types 110 4.9. Function expressions 112 4.10. Summary 114 Chapter 5. The definition and compilation of 118 G 5.1. Overview of the translation to C++ 120 5.2. A definitional compiler for 133 G 5.3. Compiler implementation details 160 5.4. Summary 162 Chapter 6. Case studies: generic libraries in 163 G 6.1. The Standard Template Library 164 6.2. The Boost Graph Library 174 6.3. Summary 180 Chapter 7. Type Safety of FG 184 7.1. FG = System F + concepts, models, and constraints 185 7.2. Translation of FG to System F 192 7.3. Isabelle/Isar formalization 201 7.4. Associated types and same-type constraints 204 7.5. Summary 213 viii Chapter 8. Conclusion 215 Appendix A. Grammar of 219 G A.1. Type expressions 220 A.2. Declarations 221 A.3. Statements and expressions 221 A.4. Derived forms 223 Appendix B. Definition of FG 224 Appendix. Bibliography 228 Appendix. Index 247 ix Software production in the large would be enormously helped by the availability of spectra of high quality routines, quite as mechanical design is abetted by the existence of families of structural shapes, screws or resistors... One could not stock 300 sine routines unless they were all in some sense instances of just a few models, highly parameterized, in which all but a few parameters were intended to be permanently bound before run time. One might call these early-bound parameters ‘sale time’ parameters... Choice of Data structures... this delicate matter requires careful plan- ning so that algorithms be as insensitive to changes of data structure as possible. When radically different structures are useful for similar problems (e.g., incidence matrix and list representations for graphs), several algorithms may be required. M. Douglas McIlroy, 1969 [126] 1 Introduction A decade or two ago computers were primarily the tools of specialists and the toys of hobby- ists. Now they are a part of everyday life: they are used to create the family photo albums, make travel reservations, communicate with friends, and get directions for a trip. Despite the advances in computer science and software engineering, computers still must be told what to do in excruciating detail. Thus, the production of software to control our computers is an important endeavor, one that affects more and more aspects of our lives. Producing software is hard: massive amounts of time and money go into creating the software applications we use today. This cost affects the prices we pay for shrink wrapped software and factors into the prices of many other goods and services. Further, software 1 1. INTRODUCTION 2 quality affects our lives: buggy software is a constant annoyance and software bugs some- times cause or contribute to more serious harm The 1968 NATO Conference on Software Engineering popularized the terms “software crisis” and “software engineering”. The crisis they faced was widespread difficulties in the construction of large software systems such as IBM’s OS/360 and the SABRE airline reservation system [64, 154]. The conference attendees felt it was time for programmers and managers to get more serious about the process of producing software. McIlroy gave an invited talk entitled Mass-produced Software Components [126]. In this talk he proposed the systematic creation of reusable software components as a solution to the software crisis. The idea was that most software products are created from building blocks that are quite similar, so software productivity would be increased if a standard set of blocks could be shared among many software products. Barnes and Bollinger define a simple equation that summarizes the savings that can be achieved through software reuse [15]. Let D stand for the cost of developing a reusable component and n be the number of uses of the component. The savings is calculated by: n (1) (Ci Ri) D ! − # − "i=1 where Ci is the cost of writing code from scratch to solve a problem and Ri is the cost of reusing the component. A particularly interesting aspect of this equation is that if Ci > Ri, then as n tends to infinity so does the savings from reuse. On the other hand, if n is small, then the benefits of reuse may be outweighed by the initial investment D of developing the reusable component. Studies by Margono and Rhoads have shown that a typical value for D is twice the cost of building a non-reusable version of the component [125]. In addition to the savings in software production, reuse can increase software quality. One of the reasons given by Lim [116] is that the more a piece of software is used, the faster the bugs in the software are found and fixed. Further, the bugs need only be fixed in one place, in the reusable component, and then all uses of the component benefit from the increase in quality.
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]
  • Thriving in a Crowded and Changing World: C++ 2006–2020
    Thriving in a Crowded and Changing World: C++ 2006–2020 BJARNE STROUSTRUP, Morgan Stanley and Columbia University, USA Shepherd: Yannis Smaragdakis, University of Athens, Greece By 2006, C++ had been in widespread industrial use for 20 years. It contained parts that had survived unchanged since introduced into C in the early 1970s as well as features that were novel in the early 2000s. From 2006 to 2020, the C++ developer community grew from about 3 million to about 4.5 million. It was a period where new programming models emerged, hardware architectures evolved, new application domains gained massive importance, and quite a few well-financed and professionally marketed languages fought for dominance. How did C++ ś an older language without serious commercial backing ś manage to thrive in the face of all that? This paper focuses on the major changes to the ISO C++ standard for the 2011, 2014, 2017, and 2020 revisions. The standard library is about 3/4 of the C++20 standard, but this paper’s primary focus is on language features and the programming techniques they support. The paper contains long lists of features documenting the growth of C++. Significant technical points are discussed and illustrated with short code fragments. In addition, it presents some failed proposals and the discussions that led to their failure. It offers a perspective on the bewildering flow of facts and features across the years. The emphasis is on the ideas, people, and processes that shaped the language. Themes include efforts to preserve the essence of C++ through evolutionary changes, to simplify itsuse,to improve support for generic programming, to better support compile-time programming, to extend support for concurrency and parallel programming, and to maintain stable support for decades’ old code.
    [Show full text]
  • David Luckham Is the Keynote Speaker at Pen,” He Says
    45-iAGEJul-Influ 14/7/04 4:02 pm Page 45 PERSPECTIVE INFLUENCER Man of events or the first year after David vision. As they do so, they will undoubt- Luckham’s book, The Power of Events, edly turn to Luckham’s book for a was published in 2002, it did what grounding in the design principles. F Power of Events most technical books do: disappeared The is based on years of into the academic ether. The publishers, research work at Stanford and two years he says, didn’t promote it at all, and its as CTO of a software start-up working in technical nature put it beyond the reach the field. The book is a technical mani- of most readers. festo for CEP – the ability of systems to As a result, it looked like the ‘event- recognise and respond to complex, inter- driven revolution’, of which the Stanford related events in real time. University Emeritus Professor is the lead- Luckham has spent 22 years as a ing and most passionate advocate, would Professor of Electrical Engineering at be postponed for a few years more. Stanford, and many years before that Stanford University But then, in mid-2003, two important doing ground-breaking work at Emeritus Professor David US technical journals gave the book Harvard, Stanford, UCLA and MIT. But highly positive reviews, and interest his presentations, and the first half of Luckham has spent began to grow. Sales began to rise, at first his book, at least, are in plain English, decades studying event slowly, then dramatically. Luckham star- full of clear examples of why CEP will processing.
    [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]
  • 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]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]
  • Java for Scientific Computing, Pros and Cons
    Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15 submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98 Springer Pub. Co. Java for Scienti c Computing, Pros and Cons Jurgen Wol v. Gudenb erg Institut fur Informatik, Universitat Wurzburg wol @informatik.uni-wuerzburg.de Abstract: In this article we brie y discuss the advantages and disadvantages of the language Java for scienti c computing. We concentrate on Java's typ e system, investi- gate its supp ort for hierarchical and generic programming and then discuss the features of its oating-p oint arithmetic. Having found the weak p oints of the language we pro- p ose workarounds using Java itself as long as p ossible. 1 Typ e System Java distinguishes b etween primitive and reference typ es. Whereas this distinc- tion seems to b e very natural and helpful { so the primitives which comprise all standard numerical data typ es have the usual value semantics and expression concept, and the reference semantics of the others allows to avoid p ointers at all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and interfaces no op erators are available or may b e de ned and expressions can only b e built by metho d calls. Several variables may simultaneously denote the same ob ject. This is certainly strange in a numerical setting, but not to avoid, since classes have to b e used to intro duce higher data typ es. On the other hand, the simple hierarchy of classes with the ro ot Object clearly b elongs to the advantages of the language.
    [Show full text]
  • A Closer Look at the Sorption Behavior of Nonionic Surfactants in Marine Sediment
    A closer look at the sorption behavior of nonionic surfactants in marine sediment Steven Droge Droge, S. / A closer look at the sorption behavior of nonionic surfactants in marine sediment. PhD thesis, 2008, Institute for Risk Assessment Sciences (IRAS), Utrecht University, The Netherlands ISBN 978-90-393-4774-4 Printed by Ridderprint Cover picture: The Great Wave off Kanagawa by Hokusai (ca. 1830-32) Design by Martijn Dorresteijn A closer look at the sorption behavior of nonionic surfactants in marine sediment Een nadere beschouwing van het sorptiegedrag van niet-ionogene oppervlakte-aktieve stoffen in marien sediment (met een samenvatting in het Nederlands) Proefschrift ter verkrijging van de graad van doctor aan de Universiteit Utrecht op gezag van de rector magnificus, prof.dr. J. C. Stoof, ingevolge het besluit van het college voor promoties in het openbaar te verdedigen op dinsdag 25 maart 2008 des middags te 4.15 uur door Stefanus Theodorus Johannes Droge geboren op 19 februari 1978 te Alkmaar Promotor: Prof.dr. W. Seinen Co-promotor: Dr. J. L. M. Hermens The research described in this thesis was financially supported by ERASM (Environmental Risk Assessment and Management), a joint platform of the European detergent and surfactants producers [A.I.S.E (Association Internationale de la Savonnerie, de la Détergence et des Produits d’Entretien) and CESIO (Comité Européen des Agents Surface et de leurs Intermédiaires Organiques)] CONTENTS Chapter 1 1 General Introduction Chapter 2 25 Analysis of Freely Dissolved Alcohol Ethoxylate Homologues
    [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]
  • Julia: a Modern Language for Modern ML
    Julia: A modern language for modern ML Dr. Viral Shah and Dr. Simon Byrne www.juliacomputing.com What we do: Modernize Technical Computing Today’s technical computing landscape: • Develop new learning algorithms • Run them in parallel on large datasets • Leverage accelerators like GPUs, Xeon Phis • Embed into intelligent products “Business as usual” will simply not do! General Micro-benchmarks: Julia performs almost as fast as C • 10X faster than Python • 100X faster than R & MATLAB Performance benchmark relative to C. A value of 1 means as fast as C. Lower values are better. A real application: Gillespie simulations in systems biology 745x faster than R • Gillespie simulations are used in the field of drug discovery. • Also used for simulations of epidemiological models to study disease propagation • Julia package (Gillespie.jl) is the state of the art in Gillespie simulations • https://github.com/openjournals/joss- papers/blob/master/joss.00042/10.21105.joss.00042.pdf Implementation Time per simulation (ms) R (GillespieSSA) 894.25 R (handcoded) 1087.94 Rcpp (handcoded) 1.31 Julia (Gillespie.jl) 3.99 Julia (Gillespie.jl, passing object) 1.78 Julia (handcoded) 1.2 Those who convert ideas to products fastest will win Computer Quants develop Scientists prepare algorithms The last 25 years for production (Python, R, SAS, DEPLOY (C++, C#, Java) Matlab) Quants and Computer Compress the Scientists DEPLOY innovation cycle collaborate on one platform - JULIA with Julia Julia offers competitive advantages to its users Julia is poised to become one of the Thank you for Julia. Yo u ' v e k i n d l ed leading tools deployed by developers serious excitement.
    [Show full text]
  • The Computational Attitude in Music Theory
    The Computational Attitude in Music Theory Eamonn Bell Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2019 © 2019 Eamonn Bell All rights reserved ABSTRACT The Computational Attitude in Music Theory Eamonn Bell Music studies’s turn to computation during the twentieth century has engendered particular habits of thought about music, habits that remain in operation long after the music scholar has stepped away from the computer. The computational attitude is a way of thinking about music that is learned at the computer but can be applied away from it. It may be manifest in actual computer use, or in invocations of computationalism, a theory of mind whose influence on twentieth-century music theory is palpable. It may also be manifest in more informal discussions about music, which make liberal use of computational metaphors. In Chapter 1, I describe this attitude, the stakes for considering the computer as one of its instruments, and the kinds of historical sources and methodologies we might draw on to chart its ascendance. The remainder of this dissertation considers distinct and varied cases from the mid-twentieth century in which computers or computationalist musical ideas were used to pursue new musical objects, to quantify and classify musical scores as data, and to instantiate a generally music-structuralist mode of analysis. I present an account of the decades-long effort to prepare an exhaustive and accurate catalog of the all-interval twelve-tone series (Chapter 2). This problem was first posed in the 1920s but was not solved until 1959, when the composer Hanns Jelinek collaborated with the computer engineer Heinz Zemanek to jointly develop and run a computer program.
    [Show full text]
  • Parallel Programming by Transformation
    Universidade do Minho Escola de Engenharia Davide Rua Carneiro An agent-based architecture for online Universidade do Minho dispute resolutionEscola services de Engenharia Parallel Programming by Transformation Rui Carlos Ara´ujoGon¸calves The MAP Doctoral Program in Computer Science The MAP-i Doctoral Program of the of the Universities of Minho, Aveiro and Porto Universities of Minho, Aveiro and Porto universidade de aveiro Universidade do Minho Supervisors: Professor Jo~aoLu´ısFerreira Sobral A thesisProfessor submitted Don Batory at the University of Minho for the degree of Doctor of Philosophy in Informatics (PhD) underApril 2015the supervision of Paulo Jorge Freitas de Oliveira Novais and José Carlos Ferreira Maia Neves July 2013 Acknowledgments Several people contributed to this journey that now is about to end. Among my family, friends, professors, etc., it is impossible to list all who helped me over the years. Nevertheless, I want to highlight some people that had a key role in the success of this journey. I would like to thank Professor Jo~aoLu´ısSobral, for bringing me into this world, for pushing me into pursuing a PhD, and for the comments and directions provided. I would like thank Professor Don Batory, for everything he taught me over these years, and for being always available to discuss my work and to share his expertise with me. I will be forever grateful for all the guidance and insights he provided me, which were essential to the conclusion of this work. I would like to thank the people I had the opportunity to work with at the University of Texas at Austin, in particular Professor Robert van de Geijn, Bryan Marker, and Taylor Rich´e,for the important contributions they gave to this work.
    [Show full text]