DOCSLIB.ORG

Mars: an Imperative/Declarative Higher-Order Programming Language with Automatic Destructive Update

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Mars: an Imperative/Declarative Higher-Order Programming Language with Automatic Destructive Update Mars An Imperative/Declarative Higher-Order Programming Language With Automatic Destructive Update Matthew Giuca Submitted in total fulfilment of the requirements of the degree of Doctor of Philosophy July 2014 Department of Computing and Information Systems The University of Melbourne i Abstract For years, we have enjoyed the robustness of programming without side-effects in lan- guages such as Haskell and Mercury. Yet in order to use languages with true referential transparency, we seem to have to give up basic imperative constructs that we have be- come accustomed to: looping constructs, variable update, destructive update of arrays, and so on. In this thesis, we explore the design of programming languages which com- bine the benefits of referential transparency with imperative-style programming. First, we present a framework for classifying programming languages according to the benefits of pure programming. Our definition applies to a wider range of languages than common terms such as “declarative” and “pure,” capturing the specific benefit of prohibiting global side-effects, without ruling out imperative programming languages. Second, we present the design and implementation for a new programming language, Mars, which allows the programmer to write imperative-style code using Python syntax, yet has the benefits of a language with referential transparency. The design philosophy behind the language, and its future directions, are discussed. Third, we note the tendency for imperative programs to use array update operations, which are very slow in a naïve implementation of any language such as Mars. We explore static analyses for automatically converting slow array copying code into fast destructive update instructions, and present the design and implementation of an optimiser for Mars, which improves on previous work by precisely handling higher-order functions, includ- ing those that both accept and return functions. The sum of this work is an efficient im- perative language with the demonstrable software engineering benefit of non-interfering functions. ii Declaration This is to certify that: (i) the thesis comprises only my original work towards the Ph.D. except where indi- cated in the Preface, (ii) due acknowledgement has been made in the text to all other material used, (iii) the thesis is fewer than 100,000 words in length, exclusive of tables, maps, bibliogra- phies and appendices. Matthew Laurence Giuca Department of Computing and Information Systems The University of Melbourne July 2014 iii Preface Drafts of Chapter 3 were written in collaboration with Dr. Peter Schachte (my Ph.D. supervisor), with the intention of publishing as a separate conference paper. The text was originally my own work, and after our collaboration, the chapter was edited heavily by myself. iv Acknowledgements Six years is a non-trivial amount of time to spend on any project, and so I have a long list of people to thank for their support and assistance. First, and foremost, I wish to thank my supervisor, Dr. Peter Schachte, for his support throughout my candidature. From the weekly insightful (and often lengthy) discussions in his office, to an ongoing email support line long after I officially left the university, Peter has always been a source of good ideas, helpful advice, and encouragement. I would also like to thank my advisory committee, Dr. Harald Søndergaard and Dr. Bernard Pope: in particular, Harald for his detailed feedback and help with Chapter 1, and Bernie for his many helpful comments and suggestions on earlier drafts of Chapter 3. I also thank the other research staff in what was the Department of Computer Science and Software Engineering during my time there, for their attendance at my talks and ongoing interest in my research. In particular, Dr. Lee Naish deserves credit for proof-reading my thesis, and pointing out the polymorphic recursion problem discussed in Section 9.6.3. I would also like to thank my two examiners, who provided many pages of detailed notes on the thesis, with thoughtful comments and suggestions. I thank my parents, Anne and Vince, and my brothers, David and Dominic, for their support. Of course, I must also thank my amazing partner, Shanika Kuruppu, who started this journey with me, and who encouraged me and waited patiently while I worked through the weekends. I would not have completed this work without Shani’s continual love and support. Finally, I would like to thank the Australian Department of Education for funding the first three and a half years of my candidature. Contents List of Figures ix 1 Introduction 1 1.1 A purely imperative programming language . .2 1.2 Automatic destructive update . .4 1.3 Contributions . .7 1.4 Conventions in this thesis . .8 1.5 Terminology . .9 1.6 Preliminaries . 10 1.7 Outline of the thesis . 17 2 Survey of hybrid imperative/declarative languages 19 2.1 Introduction . 19 2.2 Imperative languages with functional features . 23 2.3 Imperative languages with purity constraints . 24 2.4 Declarative languages with imperative constructs . 26 2.5 Languages with explicit effect annotations . 31 2.6 Conclusion . 33 3 Interface integrity 35 3.1 Introduction . 35 3.2 Interface integrity . 38 3.3 Interface integrity and language features . 43 3.4 Comparison to related concepts . 52 3.5 Language construction . 53 3.6 Conclusion . 59 4 Mars: An imperative/declarative language 61 v vi CONTENTS 4.1 Introduction . 61 4.2 Overview . 62 4.3 Standard libraries . 74 4.4 Example . 75 4.5 Conclusion . 77 5 Code representation for analysis 79 5.1 Introduction . 79 5.2 Converting Mars to MIR . 80 5.3 Converting other languages to MIR . 89 5.4 The implementation of MIR . 93 5.5 Abstract syntax . 95 5.6 Concrete value denotational semantics . 96 5.7 Concrete memory denotational semantics . 103 5.8 Conclusion . 108 6 Abstract interpretation 111 6.1 Introduction . 111 6.2 The abstract domain . 113 6.3 Abstraction and concretisation . 116 6.4 Abstract semantics . 119 6.5 Making use of the semantics . 122 6.6 Condensing semantics and context-insensitive analysis . 125 6.7 Efficient bottom-up analysis . 128 6.8 Conclusion . 131 7 Existing sharing and reuse analyses 133 7.1 Introduction . 133 7.2 Runtime reference counting . 134 7.3 Type-based approaches . 134 7.4 Compile-time garbage collection . 140 7.5 Dynamic memory reuse flags . 151 7.6 Aliasing analysis for impure and unsafe languages . 152 7.7 Dynamic aliasing analysis . 155 7.8 Static pointer nullification . 156 7.9 Conclusion . 157 8 First-order uniqueness inference 159 CONTENTS vii 8.1 Introduction . 159 8.2 Motivating examples . 160 8.3 Abstract memory denotational semantics . 174 8.4 Comparison to Mercury’s CTGC system . 189 8.5 Conclusion . 190 9 Higher-order uniqueness inference 191 9.1 Introduction . 191 9.2 Why analyse higher-order? . 192 9.3 Overview . 196 9.4 The upward higher-order problem . 199 9.5 The non-applicative downward higher-order problem . 205 9.6 The applicative downward higher-order problem . 208 9.7 Abstract memory denotational semantics . 218 9.8 Algebraic analysis . 227 9.9 Analysing non-Mars language features . 236 9.10 Conclusion . 239 10 Destructive update optimisation 241 10.1 Introduction . 241 10.2 Live-variable analysis . 242 10.3 Call mode selection . 245 10.4 Dynamic call mode vectors . 253 10.5 Multiple specialisation . 257 10.6 Higher-order call modes . 261 10.7 Structure reuse . 262 10.8 Future work . 270 10.9 Conclusion . 271 11 Conclusion 273 11.1 A pure imperative programming language . 273 11.2 Automatic destructive update . 275 11.3 Benchmarks . 276 11.4 Future work . 279 11.5 What we have built . 280 viii CONTENTS List of Figures 1.1 Linked list of boxed numbers, showing the meaning of various terms . 10 1.2 Hasse diagram for the partial order }(f0, 1g) ................. 14 3.1 Example function declaration and call syntax . 40 3.2 Effective interface (pure) . 41 3.3 Effective interface (with ref) . 42 3.4 Unintended aliasing of the player and rocket position ............ 47 3.5 The denotational semantics for L0 ........................ 54 3.6 Additions to the denotational semantics for L1 ................ 56 3.7 Additions to the denotational semantics for L2 ................ 57 3.8 Additions to the denotational semantics for L3 ................ 58 6.1 Hasse diagram for the domain f(0), (−), (+), (±)g ............. 111 6.2 Hasse diagram for the domain }(fNil, Two, Threeg) ............. 115 6.3 Call graph with.
Load more

Recommended publications
  • Programming Paradigms & Object-Oriented
    4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Syllabus Content: 4.3.1 Programming paradigms Show understanding of what is meant by a programming paradigm Show understanding of the characteristics of a number of programming paradigms (low- level, imperative (procedural), object-oriented, declarative) – low-level programming Demonstrate an ability to write low-level code that uses various address modes: o immediate, direct, indirect, indexed and relative (see Section 1.4.3 and Section 3.6.2) o imperative programming- see details in Section 2.3 (procedural programming) Object-oriented programming (OOP) o demonstrate an ability to solve a problem by designing appropriate classes o demonstrate an ability to write code that demonstrates the use of classes, inheritance, polymorphism and containment (aggregation) declarative programming o demonstrate an ability to solve a problem by writing appropriate facts and rules based on supplied information o demonstrate an ability to write code that can satisfy a goal using facts and rules Programming paradigms 1 4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Programming paradigm: A programming paradigm is a set of programming concepts and is a fundamental style of programming. Each paradigm will support a different way of thinking and problem solving. Paradigms are supported by programming language features. Some programming languages support more than one paradigm. There are many different paradigms, not all mutually exclusive. Here are just a few different paradigms. Low-level programming paradigm The features of Low-level programming languages give us the ability to manipulate the contents of memory addresses and registers directly and exploit the architecture of a given processor.
    [Show full text]
  • Functional and Imperative Object-Oriented Programming in Theory and Practice
    Uppsala universitet Inst. för informatik och media Functional and Imperative Object-Oriented Programming in Theory and Practice A Study of Online Discussions in the Programming Community Per Jernlund & Martin Stenberg Kurs: Examensarbete Nivå: C Termin: VT-19 Datum: 14-06-2019 Abstract Functional programming (FP) has progressively become more prevalent and techniques from the FP paradigm has been implemented in many different Imperative object-oriented programming (OOP) languages. However, there is no indication that OOP is going out of style. Nevertheless the increased popularity in FP has sparked new discussions across the Internet between the FP and OOP communities regarding a multitude of related aspects. These discussions could provide insights into the questions and challenges faced by programmers today. This thesis investigates these online discussions in a small and contemporary scale in order to identify the most discussed aspect of FP and OOP. Once identified the statements and claims made by various discussion participants were selected and compared to literature relating to the aspects and the theory behind the paradigms in order to determine whether there was any discrepancies between practitioners and theory. It was done in order to investigate whether the practitioners had different ideas in the form of best practices that could influence theories. The most discussed aspect within FP and OOP was immutability and state relating primarily to the aspects of concurrency and performance. ​ ​ ​ ​ ​ ​ This thesis presents a selection of representative quotes that illustrate the different points of view held by groups in the community and then addresses those claims by investigating what is said in literature.
    [Show full text]
  • Functional and Logic Programming - Wolfgang Schreiner
    COMPUTER SCIENCE AND ENGINEERING - Functional and Logic Programming - Wolfgang Schreiner FUNCTIONAL AND LOGIC PROGRAMMING Wolfgang Schreiner Research Institute for Symbolic Computation (RISC-Linz), Johannes Kepler University, A-4040 Linz, Austria, [email protected]. Keywords: declarative programming, mathematical functions, Haskell, ML, referential transparency, term reduction, strict evaluation, lazy evaluation, higher-order functions, program skeletons, program transformation, reasoning, polymorphism, functors, generic programming, parallel execution, logic formulas, Horn clauses, automated theorem proving, Prolog, SLD-resolution, unification, AND/OR tree, constraint solving, constraint logic programming, functional logic programming, natural language processing, databases, expert systems, computer algebra. Contents 1. Introduction 2. Functional Programming 2.1 Mathematical Foundations 2.2 Programming Model 2.3 Evaluation Strategies 2.4 Higher Order Functions 2.5 Parallel Execution 2.6 Type Systems 2.7 Implementation Issues 3. Logic Programming 3.1 Logical Foundations 3.2. Programming Model 3.3 Inference Strategy 3.4 Extra-Logical Features 3.5 Parallel Execution 4. Refinement and Convergence 4.1 Constraint Logic Programming 4.2 Functional Logic Programming 5. Impacts on Computer Science Glossary BibliographyUNESCO – EOLSS Summary SAMPLE CHAPTERS Most programming languages are models of the underlying machine, which has the advantage of a rather direct translation of a program statement to a sequence of machine instructions. Some languages, however, are based on models that are derived from mathematical theories, which has the advantages of a more concise description of a program and of a more natural form of reasoning and transformation. In functional languages, this basis is the concept of a mathematical function which maps a given argument values to some result value.
    [Show full text]
  • Programming Language
    Programming language A programming language is a formal language, which comprises a set of instructions that produce various kinds of output. Programming languages are used in computer programming to implement algorithms. Most programming languages consist of instructions for computers. There are programmable machines that use a set of specific instructions, rather than general programming languages. Early ones preceded the invention of the digital computer, the first probably being the automatic flute player described in the 9th century by the brothers Musa in Baghdad, during the Islamic Golden Age.[1] Since the early 1800s, programs have been used to direct the behavior of machines such as Jacquard looms, music boxes and player pianos.[2] The programs for these The source code for a simple computer program written in theC machines (such as a player piano's scrolls) did not programming language. When compiled and run, it will give the output "Hello, world!". produce different behavior in response to different inputs or conditions. Thousands of different programming languages have been created, and more are being created every year. Many programming languages are written in an imperative form (i.e., as a sequence of operations to perform) while other languages use the declarative form (i.e. the desired result is specified, not how to achieve it). The description of a programming language is usually split into the two components ofsyntax (form) and semantics (meaning). Some languages are defined by a specification document (for example, theC programming language is specified by an ISO Standard) while other languages (such as Perl) have a dominant implementation that is treated as a reference.
    [Show full text]
  • Logic Programming Logic Department of Informatics Informatics of Department Based on INF 3110 – 2016 2
    Logic Programming INF 3110 3110 INF Volker Stolz – 2016 [email protected] Department of Informatics – University of Oslo Based on slides by G. Schneider, A. Torjusen and Martin Giese, UiO. 1 Outline ◆ A bit of history ◆ Brief overview of the logical paradigm 3110 INF – ◆ Facts, rules, queries and unification 2016 ◆ Lists in Prolog ◆ Different views of a Prolog program 2 History of Logic Programming ◆ Origin in automated theorem proving ◆ Based on the syntax of first-order logic ◆ 1930s: “Computation as deduction” paradigm – K. Gödel 3110 INF & J. Herbrand – ◆ 1965: “A Machine-Oriented Logic Based on the Resolution 2016 Principle” – Robinson: Resolution, unification and a unification algorithm. • Possible to prove theorems of first-order logic ◆ Early seventies: Logic programs with a restricted form of resolution introduced by R. Kowalski • The proof process results in a satisfying substitution. • Certain logical formulas can be interpreted as programs 3 History of Logic Programming (cont.) ◆ Programming languages for natural language processing - A. Colmerauer & colleagues ◆ 1971–1973: Prolog - Kowalski and Colmerauer teams 3110 INF working together ◆ First implementation in Algol-W – Philippe Roussel – 2016 ◆ 1983: WAM, Warren Abstract Machine ◆ Influences of the paradigm: • Deductive databases (70’s) • Japanese Fifth Generation Project (1982-1991) • Constraint Logic Programming • Parts of Semantic Web reasoning • Inductive Logic Programming (machine learning) 4 Paradigms: Overview ◆ Procedural/imperative Programming • A program execution is regarded as a sequence of operations manipulating a set of registers (programmable calculator) 3110 INF ◆ Functional Programming • A program is regarded as a mathematical function – 2016 ◆ Object-Oriented Programming • A program execution is regarded as a physical model simulating a real or imaginary part of the world ◆ Constraint-Oriented/Declarative (Logic) Programming • A program is regarded as a set of equations ◆ Aspect-Oriented, Intensional, ..
    [Show full text]
  • Multi-Paradigm Declarative Languages*
    c Springer-Verlag In Proc. of the International Conference on Logic Programming, ICLP 2007. Springer LNCS 4670, pp. 45-75, 2007 Multi-paradigm Declarative Languages⋆ Michael Hanus Institut f¨ur Informatik, CAU Kiel, D-24098 Kiel, Germany. [email protected] Abstract. Declarative programming languages advocate a program- ming style expressing the properties of problems and their solutions rather than how to compute individual solutions. Depending on the un- derlying formalism to express such properties, one can distinguish differ- ent classes of declarative languages, like functional, logic, or constraint programming languages. This paper surveys approaches to combine these different classes into a single programming language. 1 Introduction Compared to traditional imperative languages, declarative programming lan- guages provide a higher and more abstract level of programming that leads to reliable and maintainable programs. This is mainly due to the fact that, in con- trast to imperative programming, one does not describe how to obtain a solution to a problem by performing a sequence of steps but what are the properties of the problem and the expected solutions. In order to define a concrete declarative language, one has to fix a base formalism that has a clear mathematical founda- tion as well as a reasonable execution model (since we consider a programming language rather than a specification language). Depending on such formalisms, the following important classes of declarative languages can be distinguished: – Functional languages: They are based on the lambda calculus and term rewriting. Programs consist of functions defined by equations that are used from left to right to evaluate expressions.
    [Show full text]
  • Mccarthy.Pdf
    HISTORY OF LISP John McCarthy A rtificial Intelligence Laboratory Stanford University 1. Introduction. 2. LISP prehistory - Summer 1956 through Summer 1958. This paper concentrates on the development of the basic My desire for an algebraic list processing language for ideas and distinguishes two periods - Summer 1956 through artificial intelligence work on the IBM 704 computer arose in the Summer 1958 when most of the key ideas were developed (some of summer of 1956 during the Dartmouth Summer Research Project which were implemented in the FORTRAN based FLPL), and Fall on Artificial Intelligence which was the first organized study of AL 1958 through 1962 when the programming language was During this n~eeting, Newell, Shaa, and Fimon described IPL 2, a implemented and applied to problems of artificial intelligence. list processing language for Rand Corporation's JOHNNIAC After 1962, the development of LISP became multi-stranded, and different ideas were pursued in different places. computer in which they implemented their Logic Theorist program. There was little temptation to copy IPL, because its form was based Except where I give credit to someone else for an idea or on a JOHNNIAC loader that happened to be available to them, decision, I should be regarded as tentatively claiming credit for It and because the FORTRAN idea of writing programs algebraically or else regarding it as a consequence of previous decisions. was attractive. It was immediately apparent that arbitrary However, I have made mistakes about such matters in the past, and subexpressions of symbolic expressions could be obtained by I have received very little response to requests for comments on composing the functions that extract immediate subexpresstons, and drafts of this paper.
    [Show full text]
  • Application and Interpretation
    Programming Languages: Application and Interpretation Shriram Krishnamurthi Brown University Copyright c 2003, Shriram Krishnamurthi This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License. If you create a derivative work, please include the version information below in your attribution. This book is available free-of-cost from the author’s Web site. This version was generated on 2007-04-26. ii Preface The book is the textbook for the programming languages course at Brown University, which is taken pri- marily by third and fourth year undergraduates and beginning graduate (both MS and PhD) students. It seems very accessible to smart second year students too, and indeed those are some of my most successful students. The book has been used at over a dozen other universities as a primary or secondary text. The book’s material is worth one undergraduate course worth of credit. This book is the fruit of a vision for teaching programming languages by integrating the “two cultures” that have evolved in its pedagogy. One culture is based on interpreters, while the other emphasizes a survey of languages. Each approach has significant advantages but also huge drawbacks. The interpreter method writes programs to learn concepts, and has its heart the fundamental belief that by teaching the computer to execute a concept we more thoroughly learn it ourselves. While this reasoning is internally consistent, it fails to recognize that understanding definitions does not imply we understand consequences of those definitions. For instance, the difference between strict and lazy evaluation, or between static and dynamic scope, is only a few lines of interpreter code, but the consequences of these choices is enormous.
    [Show full text]
  • Formalizing the Expertise of the Assembly Language Programmer
    MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLIGENCE LABORATORY Working Paper 203 September 1980 Formalizing tte Expertise of the Assembly Language Programmer Roger DuWayne Duffey II Abstract: A novel compiler strategy for generating high quality code is described. The quality of the code results from reimplementing the program in the target language using knowledge of the program's behavior. The research is a first step towards formalizing the expertise of the assembly language programmer. The ultimate goal is to formalize code generation and implementation techniques it, the same way that parsing and code generation techniques have been formalized. An experimental code generator based on the reimplementation strategy will be constructed. The code generator will provide a framework for analyzing the costs, applicability, and effectiveness of various implementation techniques. Several common code generation problems will be studied. Code written by experienced programmers and code generated by a conventional optimizing compiler will provide standards of comparison. A.I. Laboratory Working Papers are produced for internal circulation, and may contain information that is, for 4.xample, too preliminary or too detailed for formal publication. It is not intended that they should be considered papers to which reference can be made in the literature. 0 MASSACHUSETTS INSTITUTE OF TECHNOLOGY 1980 I. Introduction This research proposes a novel compiler strategy for generating high quality code. The strategy evolved .from studying the differences between the code produced by experienced programmers and the code produced by conventional optimization techniques. The strategy divides compilation into four serial stages: analyzing the source implementation, undoing source implementation decisions, reimplementing the program in the target language, and assembling the object modules.
    [Show full text]
  • ©2007 Melissa Tracey Brown ALL RIGHTS RESERVED
    ©2007 Melissa Tracey Brown ALL RIGHTS RESERVED ENLISTING MASCULINITY: GENDER AND THE RECRUITMENT OF THE ALL-VOLUNTEER FORCE by MELISSA TRACEY BROWN A Dissertation submitted to the Graduate School-New Brunswick Rutgers, The State University of New Jersey in partial fulfillment of the requirements for the degree of Doctor of Philosophy Graduate Program in Political Science written under the direction of Leela Fernandes and approved by ________________________ ________________________ ________________________ ________________________ New Brunswick, New Jersey October, 2007 ABSTRACT OF THE DISSERTATION Enlisting Masculinity: Gender and the Recruitment of the All-Volunteer Force By MELISSA TRACEY BROWN Dissertation Director: Leela Fernandes This dissertation explores how the US military branches have coped with the problem of recruiting a volunteer force in a period when masculinity, a key ideological underpinning of military service, was widely perceived to be in crisis. The central questions of this dissertation are: when the military appeals to potential recruits, does it present service in masculine terms, and if so, in what forms? How do recruiting materials construct gender as they create ideas about soldiering? Do the four service branches, each with its own history, institutional culture, and specific personnel needs, deploy gender in their recruiting materials in significantly different ways? In order to answer these questions, I collected recruiting advertisements published by the four armed forces in several magazines between 1970 and 2003 and analyzed them using an interpretive textual approach. The print ad sample was supplemented with television commercials, recruiting websites, and media coverage of recruiting. The dissertation finds that the military branches have presented several versions of masculinity, including both transformed models that are gaining dominance in the civilian sector and traditional warrior forms.
    [Show full text]
  • LISP Session
    LISP Session Chairman: Barbara Liskov Speaker: John McCarthy Discussant: Paul Abrahams PAPER: HISTORY OF LISP John McCarthy 1. Introduction This paper concentrates on the development of the basic ideas and distinguishes two periods--Summer 1956 through Summer 1958, when most of the key ideas were devel- oped (some of which were implemented in the FORTRAN-based FLPL), and Fall 1958 through 1962, when the programming language was implemented and applied to problems of artificial intelligence. After 1962, the development of LISP became multistranded, and different ideas were pursued in different places. Except where I give credit to someone else for an idea or decision, I should be regarded as tentatively claiming credit for it or else regarding it as a consequence of previous deci- sions. However, I have made mistakes about such matters in the past, and I have received very little response to requests for comments on drafts of this paper. It is particularly easy to take as obvious a feature that cost someone else considerable thought long ago. As the writing of this paper approaches its conclusion, I have become aware of additional sources of information and additional areas of uncertainty. As a programming language, LISP is characterized by the following ideas: computing with symbolic expressions rather than numbers, representation of symbolic expressions and other information by list structure in the memory of a computer, representation of in- formation in external media mostly by multilevel lists and sometimes by S-expressions, a small
    [Show full text]
  • Flexible Supply Chain Simulation
    J. Manuel Feliz-Teixeira Flexible Supply Chain Simulation Thesis 01 MARCH 2006 Text submitted in partial fulfilment for the degree of Doctor in Sciences of Engineering Supervisor António E. S. Carvalho Brito Advisor Richard Saw RESEARCH SPONSORED BY THE: THROUGH THE: PUBLISHER: Publindústria® Produção de Comunicação, Lda. EUROPEAN UNION European Social Fund (III framework) Copyright: Ó J. Manuel Feliz-Teixeira All rights reserved First Edition: Porto, 1 March 2006 ISBN: 972-8953-04-6 Legal deposit: 239362/06 Original cover art: Jorge Pereira Publisher: Publindústria, Produção de Comunicação Pr. Da Corujeira, 38 – Apt.3825 4300-144 Porto Portugal Tel: +351.22.589.96.20 Fax: +351.22.589.96.29 Email: [email protected] URL: http://www.publindustria.pt Flexible Supply Chain Simulation Thesis J. Manuel Feliz-Teixeira* 01 March 2006 Text submitted in partial fulfilment for the degree of Doctor in Sciences of Engineering Supervisor: António E. S. Carvalho Brito Advisor: Richard Saw Research sponsored by the: European Social Fund (III framework) Through the: * Complete name: José Manuel Feliz Dias Teixeira i To my mother and my father, and my old professors of Physics. J. Manuel Feliz-Teixeira IMPORTANT NOTE: NOTA IMPORTANTE: The contents of this text are registered with the Portuguese Society of Authors and protected by the law of intellectual rights, including the copyright. No reproductions or publications are allowed without the expressed permission of the author. O conteúdo desta tese encontra-se registado na Sociedade Portuguesa de Autores e está protegido pela lei geral e específica dos direitos de autor, morais e patrimoniais (copyright). Não é permitida qualquer reprodução ou publicação sem o expresso consentimento do autor.
    [Show full text]