DOCSLIB.ORG

Compilers and Compiler Generators © P.D. Terry, 2000 the Page

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Compilers and Compiler Generators © P.D. Terry, 2000 the Page Compilers and Compiler Generators © P.D. Terry, 2000 INDEX The page numbers relate to a version of the text typeset for A4 paper which is down-loadable from http://scifac.ru.ac.za/compilers/longpcl.zip as a set of PCL files suitable for direct printing to a LaserJet® compatible printer. 8-bit microprocessor 229 Automata theory 110, 143 Axiomatic semantics 69 Accumulator 25, 30 Absolute addressing 28, 46 Back end 8, 182, 217 Abstract machine 7 Backpatching 74, 219, 224, 262 Abstract syntax tree 10, 101, 181, 232, 270 Backtracking 108, 117 Accumulator machine 27 Backus-Naur form 49, 54 Activation record 246, 263 Bailes 205 Actual parameter 93, 259, 263 Base class 183, 201, 213, 232, 270 Adding machine 162 Base pointer 39, 48, 247 Address 71 BASIC PRINT statement 109 absolute 28 Beacon symbol 137, 211 field expressions 87 Binary search 201, 214 fields 72 Binary tree 82, 214, 244 immediate 28 Block structure 241 indexed 29 BNF 49, 54 indirect 29 notation 54 mode 27 extensions 59 relative 29, 46 Boolean operator 12, 46, 65, 180, 190 return 246 Bootstrap 2, 20, 22, 62 run-time 247, 250, 252, 267 Bottom-up parsing 143 Alex scanner generator 176 Bound checks 46, 228 Alias 259 Bounded buffer 286 Algol 60 report 49, 54, 106 break statement 204 Alphabet 50 Brinch Hansen 205, 216, 251, 263, 275 ALU 30, 39 British Standard for EBNF 61 Ambiguity 49, 133 Bus lines 25 Ambiguous grammar 104, 125, 133 Busy-wait 295 Analytic phase 8 Anonymous type 215 C declarations 177 Antecedent 70 Call-by-reference 259, 274 ANTLR parser generator 148 Call-by-value 259, 274 Applied occurrence 71, 191, 208 Canonical derivation 56, 104 Argument 259 CASE statement 204, 225 Arithmetic expression 100, 151, 190 Character handler 8 Arithmetic logic unit 30, 39 Character set 63, 164 ARM (Annotated Reference Manual) 70 Chomsky hierarchy 107 Array handling 212, 216, 219, 228, 268, 275 Cichelli 202 ASCII 197, 202 Clang ASSEMBLER Cocol specification 110, 220, Appendix C grammar 72 code generator interface 212, 217 language 14, 20, 71 constraint analyser 208 Assembly 7 error handling 198, 206 assembler class 75 hand-crafted parser 203, 206 code generation 75, 82 hand-crafted scanner 199 conditional 95 hand-crafted source handler 196 lexical analysis 77 report (on Diskette) macro processing 92 syntax 111 minimal 37 Clang-Topsy translator 192 one-pass 74, 83 Closure 50 semantic analysis 81 Kleene 50, 59, 65 source handling 76 positive 50 syntax analysis 79 COBEGIN ... COEND 282, 293 two-pass 73, 80 Cocktail 147 AST 10, 101, 181, 232, 270 Coco-2 176 AST code generation 181, 232, 270 Coco/R 61, 123, 146, 161, 189 Asynchronous input 297 Clang error handling 208 Attribute grammar 69, 110, 151, 157 Clang scanner 201 Augmented grammar 123 Clang specification 110, 220, Appendix C driver program 174 Concrete syntax 10 execution 162 Concrete syntax tree 10 frame file 147, 161, 175 Concurrent processes 281 ftp sites Appendix A Concurrent programming 281 installation 161, Appendix A Condition flag 30, 36, 46 makefile 162 Conditional assembly 95 parser interface 173 Consequence rule 69 scanner interface 166 Consequent 70 support modules 172 Constant declarations 124 Cocol 61, 72, 161 Constant expressions 236 actions 168 Constant folding 184, 235 ANY 164, 168 Constraint analyser 10, 73, 208 CHARACTERS 164 CONTEXT clause 165 COMMENTS 164 Context condition 157 CONTEXT clause 165 Context-free grammar 109, 135 EOF 170 Context-sensitive 73, 106, 262 formal attributes 167 Context switch 291 grammar checks 171 Contextual constraint analyser 10 IGNORE 165 continue statement 204 LexString 173 Control statement 219 NAMES 166 Conway's problem 286 parser specification 167 Critical region 284, 288 Pragmas 162, 166 Cross compiler 2, 7, 17, 22, 75 PRAGMAS 166 Cross reference generator 191 PRODUCTIONS 167 Cycle-free grammar 104 scanner interface 166 scanner specification 163 DAG (directed acyclic graph) 237 semantic errors 172 Dangling ELSE 105, 126, 133, 204, 223 SemError() 173 Data register 25 Successful() 173 Deadlock 285, 295 SynError() 173 Debugger 239 SYNC 168, 170, 208 Declaration level 243 synchronization sets 170, 207 Declaration order 278 syntax error recovery 162, 169 Declarations 81, 138, 208, 241, 245, 260, 262 TOKENS 165 Decompiler 7 user names 166 Decorated tree 10, 152 WEAK 168, 208 Defining occurrence 71, 208 weak separators 171 Delphi 3 weak terminal 168, 170 Denotational semantics 69 Code generation 12 Dereferencing 41 ASSEMBLER 82 Derived from 54 assembler code 238 Descriptor ring 291 from an AST 181, 232, 270 Designator 134, 209, 212, 252, 259, 273 generator interface 212, 217 Deterministic finite automaton (DFA) 142 native 231 Deterministic parsing 116 on-the-fly 179, 184, 226, 250, 255, 266 DFA (deterministic finite automaton) 142 one-address code 179, 181 Dijkstra 284 optimization 12, 181, 235 Direct addressing 28 reentrant code 246 Directed acyclic graph (DAG) 237 stack machine code 226 Directive Collision 91 assembler 71 Comments 51, 71, 109, 164 compiler 201 pragmatic 201 table 74 Communication 284 Directly produces 54 Compile-time 2, 71 Director set 123 Compiler 2, 7 Disassembler 7 load-and-go 7, 37, 219 Display 252, 257 multi-pass 14 Display copy 253 one-pass 14 Distributed processing 290 structure 8, 195 DLG 148 Compiler generator 4, 146 Driver program 174, 196 Dynamic link 247, 253 Free Software Foundation 19, 202 Dynamic semantics 4, 68 Front end 8, 182, 195 FSA (Finite state automata) 110, 139, 201 -free grammar 103 Function 259 -productions 58, 107, 109 assignment 264 EBNF 59 reference 260 British standard 61 return value 265, 277 expressions 60 Edison 70, 216, 225, 284 GNU project 19, 202 Effective address 28, 30, 39 Goal symbol 53, 55 Electronic mail 193 Goods trains 65 Empty set 51 GOTO statement 225, 258 Empty statement 128 Gough 202 Empty string 51, 186 Global variables 163, 242, 292 Emulation 25 gperf 202 Emulator 16 Grammar 53 single-accumulator 35, Appendix D ambiguous 104, 125, 133 stack machine 42, Appendix B attribute 69, 110, 151, 157 Environment 156 augmented 123 Equivalent grammar 100, 125, 133 checks 171 Erasure 59, 107 context-free 109, 135 Error checking code 13, 275 context-sensitive 106 Error cycle free 104 context free 136, 169, 206 -free 103 context-sensitive 172, 208 equivalent 100, 125, 133 correction 13, 80, 136 expression 57, 100, 149, 151, 179, 190 detection 80, 86, 136 graph representation 185 handling 13 hierarchy 107 recovery 13, 136, 206 L-attributed 157 reporting 13, 87, 198 left-linear 110 semantic 172 null free 103 spurious 136, 138 reduced 103 Escape sequence 200 regular 109 EXIT statement 204, 224 restrictions 102, 118, 125 Exception 13 right-linear 109 Exclusion 284 S-attributed 157 Expression transformation 125 evaluation 151, 190 type 0 107 grammar 57, 100, 149, 151, 179, 190 type 1 107 parameter 259 type 2 109 Extended BNF 59 type 3 109 Extent of identifiers 242 Graph 185 Fetch-execute cycle 26, 35, 43 Half bootstrap 21 Finite state automata (FSA) 110, 139, 162 Hand-crafted parser 203, 206 FIRST function 118, 129, 136 Hand-crafted scanner 139, 199 FOLLOW function 120, 129, 136, 206, 211 Hand-crafted source handler 196 Followers 137, 206 Hash table 90, 214, 245 FOR loop 204, 223, 279 Hashing function 90 Formal Hexadecimal literals 78 attributes 168 High-level translator 7, 14, 19, 192 language 50 Highland Gathering 66 methods 4 Host language 2, 19 parameter 93, 259 Hypothetical stack machine 38, 217, 226 semantics 67 Fortran 2, 9, 50, 60, 117, 241 IF ... THEN ... ELSE 70, 105, 125, 133, 204, 219, 223, 257 Forward Ignorable characters 63, 164 declaration 257 Immediate addressing 28 reference 73, 83, 85, 88, 159, 219, 238, 251 Implementation language 2 Frame file 147, 161, 175 Independent compilation 14 Frame header 246, 263 Index register 30 Indexed addressing 29 Loop Indivisible operation 284, 295 EXIT 224 Inductive expression 69 FOR 204, 223, 279 Inference rule 69 REPEAT 125, 223 Inherent addressing 28 WHILE 10, 68, 70, 205, 219 Inherited attribute 157 LR(k) parsing 143 Instruction pointer 26 Instruction register 25 Machine Instruction set 31, 40 abstract 7 Intermediate addressing 247 code 231 Intermediate code 11 dependencies 8 Interpreter 15 instructions 25 Interpretive compiler 15, 22 single-accumulator 30 Interrupts 26 stack 38 IOTRANSFER 297 Macro 92 assembler 7, 74, 92 Java 4 handler class 93 expansion 92, 92 Kernel 290 parameters 93 Keywords 10, 64, 125, 142, 200, 201 recursive 96 Kleene closure 50, 59, 65 Make file 66, 162 Mark stack pointer 39, 248, 263 L-attributed grammar 157 Memory-indexed addressing 29 L-value 212 Memory-indirect addressing 29 Label 71, 81, 99 Metalanguage 49 redefined 82, 85 Metasymbol 50, 59 undefined 82 Minimal perfect hashing function 202 LALR parsing 146 Mnemonic 26, 71 Lambda production 59 Modularity 4 Language 50 Multi-stage translator 14 Language design 5, 276, 280 Music 193 Left canonical derivation 56 Mutual exclusion 284 Left linear grammar 110 Mutually recursive procedures 257 Left recursion 54, 126, 152 Level, declaration 243 Native code 231 lex scanner generator 147 Name equivalence 215 Lexeme 142, 163, 199, 201 NDFA (non-deterministic finite automaton) 142 Lexical analyser 8, 58, 77, 89 Nested blocks 242 Lexical structure 58, 61, 63 Non-deterministic finite automaton (NDFA) 142 Lexicon 58 Non-reachable production 103 LexName 173 Non-terminal 53, 60 LexString 173 Non-terminating production 103 Lifetime of identifiers 242 Null Link production 58 dynamic 247, 253 string 50 static 248, 257 string problem 120 Linkage area 246 Nullable 59, 119, 130, 134 Linkage editor 7 Linker 7 Oberon 2, 3, 216, 240, 278 Literal pool 39, 48 Object language 2 Literal strings 115, 199, 228 Object orientation 3, 132, 183, 235 LL(1) conflict resolution 210, 223, 241, 245, 266, 269 occam 284 LL(1) restrictions 118, 125 Offset 226, 247, 263, 289 LL(k) parsing 117, 146 On-the-fly code generator 226 LLGen parser generator 147 One-address code 27 Load-and-go translator 7, 219 One and a half address code 27 Loader 37 One-pass assembler 74, 83 Local variables 220, 245 Opcode 27, 71 Location counter 75, 212 Open array 260, 275 Logical operator 180 Operating system 2 LOOP ..
Load more

Recommended publications
  • Dissolving a Half Century Old Problem About the Implementation of Procedures
    JID:SCICO AID:2123 /FLA [m3G; v1.221; Prn:28/08/2017; 16:24] P.1(1-12) Science of Computer Programming ••• (••••) •••–••• Contents lists available at ScienceDirect Science of Computer Programming www.elsevier.com/locate/scico Dissolving a half century old problem about the implementation of procedures Gauthier van den Hove CWI, SWAT, Science Park 123, 1098 XG Amsterdam, The Netherlands a r t i c l e i n f o a b s t r a c t Article history: We investigate the semantics of the procedure concept, and of one of the main techniques Received 21 June 2014 introduced by E. W. Dijkstra in his article Recursive Programming to implement it, namely Received in revised form 11 July 2017 the “static link,” sometimes also called “access link” or “lexical link.” We show that a Accepted 14 July 2017 confusion about that technique persists, even in recent textbooks. Our analysis is meant to Available online xxxx clarify the meaning of that technique, and of the procedure concept. Our main contribution Keywords: is to propose a better characterization of the “static link.” © Static link 2017 Elsevier B.V. All rights reserved. Block Closure Lexical scope Procedure 1. Introduction One of the first concepts introduced in the development of programming languages is the procedure concept. Its first precise definition appears in the ALGOL 60 Report, together with the static (or lexical) scope rule. Its implementation poses a number of difficulties, and the now classical solution to solve these difficulties, for ALGOL-like languages, was proposed by Dijkstra in his article Recursive Programming [1].
    [Show full text]
  • Steven Adriaensen, on the Semi-Automated Design Of
    Faculty of Science and Bio-Engineering Sciences Department of Computer Science Artificial Intelligence Laboratory On the Semi-automated Design of Reusable Heuristics with applications to hard combinatorial optimization Dissertation submitted in fulfilment of the requirements for the degree of Doctor of Science: Computer Science Steven Adriaensen Promotor: Prof. Dr. Ann Nowé (Vrije Universiteit Brussel) © 2018 Steven Adriaensen All rights reserved. No parts of this book may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the author. Abstract These days, many scientific and engineering disciplines rely on standardization and auto- mated tools. Somewhat ironically, the design of the algorithms underlying these tools is often a highly manual, ad hoc, experience- and intuition-driven process, commonly regarded as an “art” rather than a “science”. The research performed in the scope of this dissertation is geared towards improving the way we design algorithms. Here, we treat algorithm design itself as a computational problem, which we refer to as the Algorithm Design Problem (ADP). In a sense, we study “algorithms for designing algorithms”. The main topic we investigate in this framework is the possibility of solving the ADP automatically. Letting computers, rather than humans, design algorithms has numerous potential benefits. The idea of automating algorithm design is definitely not “new”. At- tempts to do so can be traced back to the origins of computer science, and, ever since, the ADP, in one form or another, has been considered in many different research communities. Therefore, we first present an overview of this vast and highly fragmented field, relating the different approaches, discussing their respective strengths and weaknesses, towards enabling a more unified approach to automated algorithm design.
    [Show full text]
  • Machine Models for Type-2 Polynomial-Time Bounded Functionals
    Syracuse University SURFACE College of Engineering and Computer Science - Former Departments, Centers, Institutes and College of Engineering and Computer Science Projects 1997 Semantics vs. Syntax vs. Computations: Machine models for type-2 polynomial-time bounded functionals James S. Royer Syracuse University, School of Computer and Information Science, [email protected] Follow this and additional works at: https://surface.syr.edu/lcsmith_other Part of the Computer Sciences Commons Recommended Citation Royer, James S., "Semantics vs. Syntax vs. Computations: Machine models for type-2 polynomial-time bounded functionals" (1997). College of Engineering and Computer Science - Former Departments, Centers, Institutes and Projects. 19. https://surface.syr.edu/lcsmith_other/19 This Article is brought to you for free and open access by the College of Engineering and Computer Science at SURFACE. It has been accepted for inclusion in College of Engineering and Computer Science - Former Departments, Centers, Institutes and Projects by an authorized administrator of SURFACE. For more information, please contact [email protected]. Semantics vs. Syntax vs. Computations Machine Models for Type-2 Polynomial-Time Bounded Functionals Intermediate Draft, Revision 2 + ǫ James S. Royer School of Computer and Information Science Syracuse University Syracuse, NY 13244 USA Email: [email protected] Abstract This paper investigates analogs of the Kreisel-Lacombe-Shoen®eld Theorem in the con- text of the type-2 basic feasible functionals. We develop a direct, polynomial-time analog of effective operation in which the time boundingon computationsismodeled after Kapronand Cook's scheme fortheirbasic poly- nomial-time functionals. We show that if P = NP, these polynomial-time effective op- erations are strictly more powerful on R (the class of recursive functions) than the basic feasible functions.
    [Show full text]
  • American National Standard Pascal Computer Programming Language
    ANSI/IEEE770X3.97-1983 American National Standard Pascal Computer Programming Language -JK- 468 hAf - A8A3 the Fe< , #109 i 1985 Distributed in cooperation with Wiley-Interscience, a division of John Wiley & Sons, Inc. FIPS PUB 109 See Notice on Inside IEEE Standard Pascal Computer Programming Language Published by The Institute of Electrical and Electronics Engineers, Inc Distributed in cooperation with Wiley-Interscience, a division of John Wiley & Sons, Inc ANSI/IEEE 770X3.97-1983 An American National Standard IEEE Standard Pascal Computer Programming Language Joint Sponsors IEEE Pascal Standards Committee of the IEEE Computer Society and ANSI/X3J9 of American National Standards Committee X3 Approved September 17, 1981 IEEE Standards Board Approved December 16, 1982 American National Standards Institute This standard has been adopted for U.S. federal government use. Details concerning its use within the federal government are contained in FIPS PUB 109, Pascal Computer Programming Language. For a complete list of the publications available in the FEDERAL INFORMATION PROCESSING STAN¬ DARDS Series, write to the Standards Processing Coordinator, Institute for Com¬ puter Sciences and Technology, National Bureau of Standards, Gaithersburg, MD 20899, U.S.A. Third Printing (8% X 11) for NTIS ISBN 0-471-88944-X Library of Congress Catalog Number 82-84259 © Copyright 1979 Institute of Electrical and Electronics Engineers, Inc © Copyright 1983 American National Standards Institute, Inc and Institute of Electrical and Electronics Engineers, Inc No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. Published by The Institute of Electrical and Electronics Engineers, Inc 345 East 47th Street, New York, NY 10017 January 7, 1983 SH08912 Foreword (This Foreword is not a part of ANSI/IEEE770X3.97-1983, IEEE Standard Pascal Com¬ puter Programming Language.) This standard provides an unambiguous and machine independent defini¬ tion of the language Pascal.
    [Show full text]
  • Syntactic Control of Interference Revisited
    Syracuse University SURFACE College of Engineering and Computer Science - Former Departments, Centers, Institutes and College of Engineering and Computer Science Projects 1995 Syntactic Control of Interference Revisited Peter W. O'Hearn Syracuse University A. J. Power University of Edinburgh M. Takeyama University of Edinburgh R. D. Tennent Queen's University Follow this and additional works at: https://surface.syr.edu/lcsmith_other Part of the Programming Languages and Compilers Commons Recommended Citation O'Hearn, Peter W.; Power, A. J.; Takeyama, M.; and Tennent, R. D., "Syntactic Control of Interference Revisited" (1995). College of Engineering and Computer Science - Former Departments, Centers, Institutes and Projects. 12. https://surface.syr.edu/lcsmith_other/12 This Article is brought to you for free and open access by the College of Engineering and Computer Science at SURFACE. It has been accepted for inclusion in College of Engineering and Computer Science - Former Departments, Centers, Institutes and Projects by an authorized administrator of SURFACE. For more information, please contact [email protected]. OHearn et al Syntactic Control of Interference Revisited P W OHearn Syracuse University Syracuse New York USA A J Power and M Takeyama University of Edinburgh Edinburgh Scotland EH JZ R D Tennent Queens University Kingston Canada KL N Dedicated to John C Reynolds in honor of his th birthday Abstract In Syntactic Control of Interference POPL J C Reynolds prop oses three design principles intended to constrain the scop e
    [Show full text]
  • Sequential Program Structures
    Jim Welsh, John Elder and David Bustard Sequential Program Structures C. A. R. HOARE SERIES EDITOR SEQUENTIAL PROGRAM STRUCTURES St. Olaf College JUL 3 1984 Science Library Prentice-Hall International Series in Computer Science C. A. R. Hoare, Series Editor Published backhouse, r. c.. Syntax of Programming Languages: Theory and Practice de barker, J. w„ Mathematical Theory of Program Correctness bjorner, D, and jones, c„ Formal Specification and Software Development clark, k. L. and McCabe, f. g„ micro-PROLOG: Programming in Logic dromey, r. G., How to Solve it by Computer duncan, f.. Microprocessor Programming and Software Development goldschlager, l. and lister, a., Computer Science: A Modern Introduction henderson, p.. Functional Programming: Application and Implementation inmos ltd., The Occam Programming Manual jackson, m. a., System Development jones, c, b., Software Development: A Rigorous Approach Joseph, m., prasad, v. r., and natarajan, n„ A Multiprocessor Operating System MacCALLUM, I. Pascal for the Apple Reynolds, J. c„ The Craft of Programming tennent, r. d., Principles of Programming Languages welsh, j., and elder, j.. Introduction to Pascal, 2nd Edition welsh, J., elder, j. and bustard, d., Sequential Program Structures welsh, j., and McKEag, m.. Structured System Programming SEQUENTIAL PROGRAM STRUCTURES JIM WELSH University of Queensland, Australia JOHN ELDER Queen's University of Belfast and DAVID BUSTARD Queen's University of Belfast St. Olaf College JUL 3 1984 Science Library Prentice/Hall International ENGLEWOOD CLIFFS, NEW JERSEY LONDON NEW DELHI RIO DE JANEIRO SINGAPORE SYDNEY TOKYO TORONTO WELLINGTON Library of Congress Cataloging in Publication Data Welsh, Jim, 1943- Sequential program structures. Bibliography: p. Includes index.
    [Show full text]
  • Data and Control Coupling Between Code Components
    Data Coupling and Control Coupling Technical Note Author: Professor M. A. Hennell Data Coupling and Control Coupling Introduction This document describes the features of the LDRA tool suite that contribute to the DO-178B/C Data Coupling and Control Coupling objectives. In this section the definitions and descriptions of these terms from the DO-178C standard are reproduced and the next section describes some of the faults that these objectives are designed to detect. The third section describes how the LDRA tool suite contributes to the certification process for these objectives. Definitions of the relevant terms presented in the Glossary section of Annex B of DO- 178C are as follow: Data coupling – The dependence of a software component on data not exclusively under the control of that software component. Control coupling – The manner or degree by which one software component influences the execution of another software component. In addition the definition of component is given as: Component – A self contained part, combination of parts, subassemblies, or units that perform a distinct function of a system. In general this term is interpreted as including: procedures, functions, subroutines, modules and other similar programming constructs. The objective which is required to be achieved, table A-7 objective 8, is described as follows: 6.4.4 d. Test coverage of software structure, both data coupling and control coupling, is achieved. Then in 6.4.4.2.c this activity is further clarified as follows: c. Analysis to confirm that the requirements-based testing has exercised the data and control coupling between code components. Examples of clarifications between DO-178B and DO-178C include: i.
    [Show full text]
  • Syntactic Manipulation Systems for Context-Dependent Languages
    SYNTACTIC MANIPULATION SYSTEMS FOR CONTEXT-DEPENDENT LANGUAGES Michael Dyck B.Sc., University of Winnipeg, 1984 THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE in the -School of Computing Science @ Michael Dyck 1990 SIMON FRASER UNIVERSITY August 1990 All rights reserved. This work may not be reproduced in whole or in part, by photocopy or other means, without permission of the author. APPROVAL Name: Michael Dyck Degree: Master of Science Title of thesis: Syntactic Manipulation Systems for Context-Dependent Languages Examining Committee: Chair: Dr. Binay Bhattacharya Dr. Rob Cameron Senior Supervisor ~ommittceMember Dr. Nick Cercone Committee Member Dr. Warren Burton Examiner Date Approved: 1990 August 10 PARTIAL COPYRIGHT LICENSE I hereby grant to Slmon Fraser Unlverslty the right to lend my thesis, project or extended essay (the title of which is shown below) to users of the Simon Fraser University Llbrary, and to make partial or single copies only for such users or in response to a request from the library of any other universlty, or other educational Institution, on its own behalf or for one of Its users. 1 further agree that permission for multlple copying of this work for scholarly purposes may be granted by me or the Dean of Graduate Studies. It is understood that copying or publication of this work for financial gain shall not be allowed without my written permission. T i t l e of Thes i s/Project/Extended Essay Syntactic Manipulation Systems for Context-Dependent Languages. Author : (s,t&ature) John Michael Dyck ( name (date ABSTRACT Software developers use many tools to increase their efficiency and improve their software.
    [Show full text]
  • Chapter 5 of Concrete Abstractions: an Introduction to Computer
    Out of print; full text available for free at http://www.gustavus.edu/+max/concrete-abstractions.html CHAPTER FIVE Higher-Order Procedures 5.1 Procedural Parameters In the earlier chapters, we twice learned how to stop writing lots of speci®c expressions that differed only in details and instead to write one general expression that captured the commonality: In Chapter 1, we learned how to de®ne procedures. That way when we had several expressions that differed only in the speci®c values being operated on, such as (* 3 3), (* 4 4),and(*55), we could instead de®ne a general procedure: (define square (lambda (x) (* x x))) This one procedure can be used to do all of the speci®c calculations just listed; the procedure speci®es what operations to do, and the parameter allows us to vary which value is being operated on. In Chapter 2, we learned how to generate variable-size computational processes. That way if we had several procedures that generated processes of the same form, but differing in size, such as (define square (lambda (x) (* x x))) and (define cube (lambda (x) (* (* x x) x))), we could instead de®ne a general procedure: (define power (lambda (b e) (if (= e 1) b (* (power b (- e 1)) b)))) Excerpted from Concrete Abstractions; copyright © 1999 by Max Hailperin, Barbara Kaiser, and Karl Knight 109 110 Chapter 5 Higher-Order Procedures This one procedure can be used in place of the more speci®c procedures listed previously; the procedure still speci®es what operations to do, but the parameters now specify how many of these operations to do as well as what values to do them to.
    [Show full text]
  • On the Origin of Recursive Procedures
    c The British Computer Society 2014. All rights reserved. For Permissions, please email: [email protected] Advance Access publication on 11 December 2014 doi:10.1093/comjnl/bxu145 On the Origin of Recursive Procedures Gauthier van den Hove∗ CWI, SWAT, Science Park 123, 1098 XG Amsterdam, The Netherlands ∗Corresponding author: [email protected] We investigate the origin of recursive procedures in imperative programming languages. We attempt to set the record straight, and to identify the trend that led to recursive procedures, by means of an analysis of the related concepts and of the most reliable available documents, as far as known to us. We show that not all of those who were involved in defining these concepts in these documents were fully aware of the implications of their proposals. Our aim is not primarily historical, but to contribute to a clarification of some of the concepts related to recursion. In particular, we demonstrate that recursive procedure declarations and recursive procedure activations are logically Downloaded from disjoint concepts. Keywords: procedure; recursion; declaration and activation; self-application; call by name Received 27 June 2014; revised 17 October 2014 Handling editor: Manfred Broy http://comjnl.oxfordjournals.org/ 1. INTRODUCTION [. .] [O]n about 1960 February 10, [. .] I had a telephone call from A. van Wijngaarden, speaking also for E. W. Dijkstra. They It is well-known that the first programming language in which pointed to an important lack of definition in the draft report, recursive procedures were included is J. McCarthy’s LISP. namely the meaning, if any, of an occurrence of a procedure However, he did not consider them explicitly in his first drafts identifier inside the body of the declaration other than in the left of the language, and it is only around January 1959, that is, two part of an assignment.
    [Show full text]
  • Inverse Design of Urban Procedural Models
    Inverse Design of Urban Procedural Models Carlos A. Vanegas Ignacio Garcia-Dorado Daniel G. Aliaga Bedrich Benes Paul Waddell Purdue University Purdue University Purdue University Purdue University U.C. Berkeley U.C. Berkeley b c d Initial residential place types Non-optimized sun exposure and interior light Non-optimized distance to closest park a Development site f Final design e Figure 1: Example Urban Design Process. The user interactively controls a 3D urban model by altering the parameters of an underlying procedural model (forward modeling) or by changing the values of arbitrary target indicator functions (inverse modeling). a) Starting with a development site, b) the user selects an initial urban layout (using templates or ”place types”). The layout now has parcel egress but has c) initial undesired values of building sun-exposure and natural interior light, and d) unwanted average distance from buildings to closest parks. The model alterations needed to obtain user-specified local or global values for these indicator values are computed ”inversely” resulting in a final design, which is e) seen up close or f) from a distance. In contrast, accomplishing such an output with traditional forward modeling would require either specifically writing a procedural model with the desired parameters or very careful parameter tuning by an expert to obtain the intended results. Abstract Links: DL PDF 1 Introduction We propose a framework that enables adding intuitive high level control to an existing urban procedural model. In particular, we pro- Urban procedural modeling is becoming increasingly popular in vide a mechanism to interactively edit urban models, a task which is computer graphics and urban planning applications.
    [Show full text]
  • Thesis Sci 2008 Hultquist Carl.Pdf
    Town The copyright of this thesis rests with the University of Cape Town. No quotation from it or information derivedCape from it is to be published without full acknowledgement of theof source. The thesis is to be used for private study or non-commercial research purposes only. University AN ADJECTIVAL INTERFACE FOR PROCEDURAL CONTENT GENERATION a dissertation submitted to the department of computer science, faculty of science at the university of cape town in fulfilment of the requirements for the degree of Town doctor of philosophy By CarlCape Hultquist ofDecember 2008 Supervised by James Gain and David Cairns University ii Town Cape c Copyright 2009 byof Carl Hultquist University iii Abstract In this thesis, a new interface for the generation of procedural content is proposed, in which the user describes the content that they wish to create by using adjectives. Procedural models are typi- cally controlled by complex parameters and often require expert technical knowledge. Since people communicate with each other using language, an adjectival interface to the creation of procedural content is a natural step towards addressing the needs of non-technicalTown and non-expert users. The key problem addressed is that of establishing a mapping between adjectival descriptors, and the parameters employed by procedural models. We show how this can be represented as a mapping between two multi-dimensional spaces, adjective space and parameter space, and approximate the mapping by applying novel function approximationCape techniques to points of correspondence between the two spaces. These corresponding pointof pairs are established through a training phase, in which random procedural content is generated and then described, allowing one to map from parameter space to adjective space.
    [Show full text]