DOCSLIB.ORG

LAZY EVALUATION from Natural Semantics to a Machine-Checked Compiler Transformation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Joachim Breitner LAZY EVALUATION From natural semantics to a machine-checked compiler transformation Joachim Breitner Lazy Evaluation From natural semantics to a machine-checked compiler transformation The cover background pattern was created using the substrate algorithm by J. Tarbell, as implemented for the XScreensaver project by Mike Kershaw. Lazy Evaluation From natural semantics to a machine-checked compiler transformation by Joachim Breitner Dissertation, Karlsruher Institut für Technologie (KIT) Fakultät für Informatik, 2016 Tag der mündlichen Prüfung: 25. April 2016 Erster Gutachter: Prof. Dr.-Ing. Gregor Snelting Zweiter Gutachter: Prof. Tobias Nipkow, Ph.D. Impressum Karlsruher Institut für Technologie (KIT) KIT Scientific Publishing Straße am Forum 2 D-76131 Karlsruhe KIT Scientific Publishing is a registered trademark of Karlsruhe Institute of Technology. Reprint using the book cover is not allowed. www.ksp.kit.edu This document – excluding the cover, pictures and graphs – is licensed under the Creative Commons Attribution-Share Alike 3.0 DE License (CC BY-SA 3.0 DE): http://creativecommons.org/licenses/by-sa/3.0/de/ The cover page is licensed under the Creative Commons Attribution-No Derivatives 3.0 DE License (CC BY-ND 3.0 DE): http://creativecommons.org/licenses/by-nd/3.0/de/ Print on Demand 2016 ISBN 978-3-7315-0546-4 DOI 10.5445/KSP/1000056002 Contents 1 Introduction 1 1.1 Notation and conventions . .5 1.2 Reproducibility and artefacts . .6 1.3 Lazy evaluation . .7 1.4 The GHC Haskell compiler . .9 1.4.1 GHC Core . .9 1.4.2 Rewrite rules and list fusion . 12 1.4.3 Evaluation and function arities . 15 1.5 Arities and eta-expansion . 17 1.6 Nominal logic . 19 1.6.1 Permutation sets . 20 1.6.2 Support and freshness . 21 1.6.3 Abstractions . 22 1.6.4 Strong induction rules . 22 1.6.5 Equivariance . 23 1.7 Isabelle . 24 1.7.1 The prettiness of Isabelle code . 25 1.7.2 Nominal logic in Isabelle . 28 1.7.3 Domain theory and the HOLCF package . 29 i Contents 2 Formalizing Launchbury’s natural semantics 33 2.1 Launchbury’s semantics . 34 2.1.1 Natural semantics . 35 2.1.2 Denotational semantics . 39 2.1.3 Discussions of modifications . 42 2.2 Correctness . 45 2.2.1 Discussions of modifications . 51 2.3 Adequacy . 52 2.3.1 The resourced denotational semantics . 52 2.3.2 Denotational black holes . 54 2.3.3 Resourced adequacy . 56 2.3.4 Relating the denotational semantics . 58 2.3.5 Concluding the adequacy . 59 2.3.6 Discussions of modifications . 59 2.4 Data type encodings and base values . 62 2.4.1 Data types via Church encoding . 62 2.4.2 Adding Booleans . 64 2.5 A small-step semantics . 68 2.5.1 Sestoft’s mark-1 abstract machine . 69 2.5.2 Relating Sestoft’s and Launchbury’s semantics . 70 2.5.3 Discussions of modifications . 74 2.6 The Isabelle formalisation . 76 2.6.1 Employing nominal logic . 76 2.6.2 The type of environments . 77 2.6.3 Abstracting over the denotational semantics . 79 2.6.4 Relating the domains Value and CValue ...... 82 2.7 Related work . 84 3 Call Arity 87 3.1 The need for co-call analysis . 89 3.1.1 A syntactical analysis . 89 3.1.2 Incoming arity . 90 3.1.3 Called-once information . 91 3.1.4 Mutually exclusive calls . 92 3.1.5 Co-call analysis . 93 ii Contents 3.2 The type of co-call graphs . 94 3.3 The Call Arity analysis . 95 3.3.1 The specification . 95 3.3.2 The equations . 97 3.4 The implementation . 105 3.4.1 Interesting variables . 106 3.4.2 Finding the fixed points . 107 3.4.3 Top-level values . 108 3.4.4 The graph data structure . 109 3.5 Discussion . 110 3.5.1 Call Arity and list fusion . 110 3.5.2 Limitations . 111 3.5.3 Measurements . 113 3.5.4 Compiler performance . 118 3.6 Related work . 119 3.6.1 GHC’s arity analyses . 119 3.6.2 Higher order sharing analyses . 121 3.6.3 Explicit one-shot annotation . 122 3.6.4 unfoldr/destroy and stream fusion . 124 3.6.5 Worker-wrapper list fusion . 124 3.6.6 Control flow based analyses . 126 3.7 Future work . 126 3.7.1 Improvements to the analysis . 127 3.7.2 Tighter integration into GHC . 127 4 The safety of Call Arity 129 4.1 Proof outline . 130 4.2 Arity analyses . 133 4.2.1 A concrete arity analysis . 140 4.2.2 Functional correctness . 141 4.3 Cardinality analyses . 146 4.3.1 Abstract cardinality analysis . 146 4.3.2 Trace tree cardinality analysis . 151 4.3.3 Co-call cardinality analysis . 158 4.3.4 Call Arity, concretely . 164 iii Contents 4.4 The Isabelle formalisation . 166 4.4.1 Size and effort . 166 4.4.2 Structure . 167 4.4.3 The trace tree type implementation . 167 4.5 The formalisation gap . 171 4.5.1 Core vs. my syntax . 172 4.5.2 Core vs. my semantics . 172 4.5.3 Core’s annotations . 174 4.5.4 Implementation vs. formalisation . 175 4.5.5 Performance and safety in the larger context . 176 4.6 Related work . 176 5 Conclusion 179 A Formal definitions and main theorems 183 A.1 Terms . 184 A.2 Semantics . 187 A.2.1 Natural semantics . 187 A.2.2 Small-step semantics . 188 A.2.3 Denotational semantics . 188 A.3 Correctness and adequacy theorems . 190 A.4 Call Arity . 190 A.4.1 Arities . 190 A.4.2 Co-call graphs . 192 A.4.3 The Call Arity analysis . 193 A.4.4 Call Arity theorems . 195 B Call Arity code 197 B.1 Co-call graphs . 197 B.2 The Call Arity analysis . 200 Bibliography 211 Index 223 iv Abstract High level programming languages, in particular the lazy, pure, func- tional kind, liberate the programmer from having to think about the low-level details of how his code is going to be executed, and they give the compiler extra leeway in optimising the program. This distance to the actual machine makes it harder to reason about the effect of the com- piler’s transformations on the program’s performance. Therefore, these transformations are often only evaluated empirically by measuring the performance of a few benchmark programs. This yields useful evidence, but not universal assurance. Formal semantics of programming languages can serve as guide rails to the implementation of a compiler, and formal proofs can universally show that the compiler does not inadvertently change the meaning of a program. Can they also be used effectively to establish that a program transformation performed by the compiler is indeed an optimisation? In this thesis, I answer this question in three steps: I develop a new compiler transformation; I build the tools to analyse it in an interactive theorem prover; finally I prove safety of the transformation, i.e. that the transformed program – in a suitable abstract sense – performs at least as well as the original one. My compiler transformation and accompanying program analysis Call Arity, which is now shipped with the Haskell compiler GHC, solves v Abstract a long-standing problem with the list fusion program transformation: Accumulator passing list consumers like foldl and sum would, if they were allowed to take part in list fusion, produce badly performing code. Call Arity empowers the compiler to further rewrite such code, by eta- expanding function definitions, into a form that runs efficiently again. The key ingredient is a novel cardinality analysis based on the notion of co-call graphs, which can detect whether a variable is used at most once, even in the presence of recursion. I provide empirical evidence that my analysis is indeed able to solve the problem: Now list fusion can provide significant improvements in these cases. The measurements also show that there are instances besides list fusion where the transformation fires and improves the program. No program in the benchmark suite regressed as a result of introducing Call Arity. In order to be able to verify these statements formally, I formalise Launch- bury’s natural semantics for lazy evaluation in the interactive theorem prover Isabelle. As Launchbury’s semantics is a very successful and commonly accepted semantics for lambda calculus with mutually re- cursive let-bindings that models lazy evaluation, it is a natural choice for this endeavour. My formalisation uses nominal logic, in the form of the Isabelle pack- age Nominal2, to handle the issue of names and binders, which is gener- ally one of the main hurdles in any formalisation work in programming languages. It is one of the largest Isabelle developments using this method, and the first to effectively combine it with the HOLCF package for domain theory. My first attempt to combine these turned out to be a dead end. I explain how and why that did not go well and how I eventually overcame the challenges. Furthermore, I give the first rigorous adequacy proof of Launchbury’s semantics. The proof sketch given by Launchbury has resisted past attempts to complete it. I found a more elegant and direct proof by slightly deviating from his outline. Equipped with this formalisation, I model the Call Arity analysis and transformation in Isabelle and prove that it does not degrade program vi Abstract performance. My abstract measure of performance is the number of allocations performed by the program; I explain why this is a suitable choice for my use case.
Recommended publications
  • CSCI 2041: Lazy Evaluation

    CSCI 2041: Lazy Evaluation

    CSCI 2041: Lazy Evaluation Chris Kauffman Last Updated: Wed Dec 5 12:32:32 CST 2018 1 Logistics Reading Lab13: Lazy/Streams I Module Lazy on lazy Covers basics of delayed evaluation computation I Module Stream on streams A5: Calculon Lambdas/Closures I Arithmetic language Briefly discuss these as they interpreter pertain Calculon I 2X credit for assignment I 5 Required Problems 100pts Goals I 5 Option Problems 50pts I Eager Evaluation I Milestone due Wed 12/5 I Lazy Evaluation I Final submit Tue 12/11 I Streams 2 Evaluation Strategies Eager Evaluation Lazy Evaluation I Most languages employ I An alternative is lazy eager evaluation evaluation I Execute instructions as I Execute instructions only as control reaches associated expression results are needed code (call by need) I Corresponds closely to I Higher-level idea with actual machine execution advantages and disadvantages I In pure computations, evaluation strategy doesn’t matter: will produce the same results I With side-effects, when code is run matter, particular for I/O which may see different printing orders 3 Exercise: Side-Effects and Evaluation Strategy Most common place to see differences between Eager/Lazy eval is when functions are called I Eager eval: eval argument expressions, call functions with results I Lazy eval: call function with un-evaluated expressions, eval as results are needed Consider the following expression let print_it expr = printf "Printing it\n"; printf "%d\n" expr; ;; print_it (begin printf "Evaluating\n"; 5; end);; Predict results and output for both Eager and Lazy Eval strategies 4 Answers: Side-Effects and Evaluation Strategy let print_it expr = printf "Printing it\n"; printf "%d\n" expr; ;; print_it (begin printf "Evaluating\n"; 5; end);; Evaluation > ocamlc eager_v_lazy.ml > ./a.out Eager Eval # ocaml’s default Evaluating Printing it 5 Lazy Eval Printing it Evaluating 5 5 OCaml and explicit lazy Computations I OCaml’s default model is eager evaluation BUT.
  • Process Synchronisation Background (1)

    Process Synchronisation Background (1)

    Process Synchronisation Background (1) Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes Producer Consumer Background (2) Race condition count++ could be implemented as register1 = count register1 = register1 + 1 count = register1 count- - could be implemented as register2 = count register2 = register2 - 1 count = register2 Consider this execution interleaving with ―count = 5‖ initially: S0: producer execute register1 = count {register1 = 5} S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = count {register2 = 5} S3: consumer execute register2 = register2 - 1 {register2 = 4} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4} Solution: ensure that only one process at a time can manipulate variable count Avoid interference between changes Critical Section Problem Critical section: a segment of code in which a process may be changing Process structure common variables ◦ Only one process is allowed to be executing in its critical section at any moment in time Critical section problem: design a protocol for process cooperation Requirements for a solution ◦ Mutual exclusion ◦ Progress ◦ Bounded waiting No assumption can be made about the relative speed of processes Handling critical sections in OS ◦ Pre-emptive kernels (real-time programming, more responsive) Linux from 2.6, Solaris, IRIX ◦ Non-pre-emptive kernels (free from race conditions) Windows XP, Windows 2000, traditional UNIX kernel, Linux prior 2.6 Peterson’s Solution Two process solution Process Pi ◦ Mutual exclusion is preserved? ◦ The progress requirements is satisfied? ◦ The bounded-waiting requirement is met? Assumption: LOAD and STORE instructions are atomic, i.e.
  • Gnu Smalltalk Library Reference Version 3.2.5 24 November 2017

    Gnu Smalltalk Library Reference Version 3.2.5 24 November 2017

    gnu Smalltalk Library Reference Version 3.2.5 24 November 2017 by Paolo Bonzini Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". 1 3 1 Base classes 1.1 Tree Classes documented in this manual are boldfaced. Autoload Object Behavior ClassDescription Class Metaclass BlockClosure Boolean False True CObject CAggregate CArray CPtr CString CCallable CCallbackDescriptor CFunctionDescriptor CCompound CStruct CUnion CScalar CChar CDouble CFloat CInt CLong CLongDouble CLongLong CShort CSmalltalk CUChar CByte CBoolean CUInt CULong CULongLong CUShort ContextPart 4 GNU Smalltalk Library Reference BlockContext MethodContext Continuation CType CPtrCType CArrayCType CScalarCType CStringCType Delay Directory DLD DumperProxy AlternativeObjectProxy NullProxy VersionableObjectProxy PluggableProxy SingletonProxy DynamicVariable Exception Error ArithmeticError ZeroDivide MessageNotUnderstood SystemExceptions.InvalidValue SystemExceptions.EmptyCollection SystemExceptions.InvalidArgument SystemExceptions.AlreadyDefined SystemExceptions.ArgumentOutOfRange SystemExceptions.IndexOutOfRange SystemExceptions.InvalidSize SystemExceptions.NotFound SystemExceptions.PackageNotAvailable SystemExceptions.InvalidProcessState SystemExceptions.InvalidState
  • Learning Javascript Design Patterns

    Learning Javascript Design Patterns

    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
  • Bespoke Tools: Adapted to the Concepts Developers Know

    Bespoke Tools: Adapted to the Concepts Developers Know

    Bespoke Tools: Adapted to the Concepts Developers Know Brittany Johnson, Rahul Pandita, Emerson Murphy-Hill, and Sarah Heckman Department of Computer Science North Carolina State University, Raleigh, NC, USA {bijohnso, rpandit}@ncsu.edu, {emerson, heckman}@csc.ncsu.edu ABSTRACT Such manual customization is undesirable for several rea- Even though different developers have varying levels of ex- sons. First, to choose among alternative tools, a developer pertise, the tools in one developer's integrated development must be aware that alternatives exist, yet lack of awareness environment (IDE) behave the same as the tools in every is a pervasive problem in complex software like IDEs [3]. other developers' IDE. In this paper, we propose the idea of Second, even after being aware of alternatives, she must be automatically customizing development tools by modeling able to intelligently choose which tool will be best for her. what a developer knows about software concepts. We then Third, if a developer's situation changes and she recognizes sketch three such \bespoke" tools and describe how devel- that the tool she is currently using is no longer the optimal opment data can be used to infer what a developer knows one, she must endure the overhead of switching to another about relevant concepts. Finally, we describe our ongoing ef- tool. Finally, customization takes time, time that is spent forts to make bespoke program analysis tools that customize fiddling with tools rather than developing software. their notifications to the developer using them. 2. WHAT IS THE NEW IDEA? Categories and Subject Descriptors Our idea is bespoke tools: tools that automatically fit D.2.6 [Software Engineering]: Programming Environments| themselves to the developer using them.
  • An Analysis of the Dynamic Behavior of Javascript Programs

    An Analysis of the Dynamic Behavior of Javascript Programs

    An Analysis of the Dynamic Behavior of JavaScript Programs Gregor Richards Sylvain Lebresne Brian Burg Jan Vitek S3 Lab, Department of Computer Science, Purdue University, West Lafayette, IN fgkrichar,slebresn,bburg,[email protected] Abstract becoming a general purpose computing platform with office appli- The JavaScript programming language is widely used for web cations, browsers and development environments [15] being devel- programming and, increasingly, for general purpose computing. oped in JavaScript. It has been dubbed the “assembly language” of the Internet and is targeted by code generators from the likes As such, improving the correctness, security and performance of 2;3 JavaScript applications has been the driving force for research in of Java and Scheme [20]. In response to this success, JavaScript type systems, static analysis and compiler techniques for this lan- has started to garner academic attention and respect. Researchers guage. Many of these techniques aim to reign in some of the most have focused on three main problems: security, correctness and dynamic features of the language, yet little seems to be known performance. Security is arguably JavaScript’s most pressing prob- about how programmers actually utilize the language or these fea- lem: a number of attacks have been discovered that exploit the lan- tures. In this paper we perform an empirical study of the dynamic guage’s dynamism (mostly the ability to access and modify shared behavior of a corpus of widely-used JavaScript programs, and an- objects and to inject code via eval). Researchers have proposed ap- alyze how and why the dynamic features are used.
  • Control Flow

    Control Flow

    Control Flow COMS W4115 Prof. Stephen A. Edwards Spring 2002 Columbia University Department of Computer Science Control Flow “Time is Nature’s way of preventing everything from happening at once.” Scott identifies seven manifestations of this: 1. Sequencing foo(); bar(); 2. Selection if (a) foo(); 3. Iteration while (i<10) foo(i); 4. Procedures foo(10,20); 5. Recursion foo(int i) { foo(i-1); } 6. Concurrency foo() jj bar() 7. Nondeterminism do a -> foo(); [] b -> bar(); Ordering Within Expressions What code does a compiler generate for a = b + c + d; Most likely something like tmp = b + c; a = tmp + d; (Assumes left-to-right evaluation of expressions.) Order of Evaluation Why would you care? Expression evaluation can have side-effects. Floating-point numbers don’t behave like numbers. Side-effects int x = 0; int foo() { x += 5; return x; } int a = foo() + x + foo(); What’s the final value of a? Side-effects int x = 0; int foo() { x += 5; return x; } int a = foo() + x + foo(); GCC sets a=25. Sun’s C compiler gave a=20. C says expression evaluation order is implementation-dependent. Side-effects Java prescribes left-to-right evaluation. class Foo { static int x; static int foo() { x += 5; return x; } public static void main(String args[]) { int a = foo() + x + foo(); System.out.println(a); } } Always prints 20. Number Behavior Basic number axioms: a + x = a if and only if x = 0 Additive identity (a + b) + c = a + (b + c) Associative a(b + c) = ab + ac Distributive Misbehaving Floating-Point Numbers 1e20 + 1e-20 = 1e20 1e-20 1e20 (1 + 9e-7) + 9e-7 6= 1 + (9e-7 + 9e-7) 9e-7 1, so it is discarded, however, 1.8e-6 is large enough 1:00001(1:000001 − 1) 6= 1:00001 · 1:000001 − 1:00001 · 1 1:00001 · 1:000001 = 1:00001100001 requires too much intermediate precision.
  • 210 CHAPTER 7. NAMES and BINDING Chapter 8

    210 CHAPTER 7. NAMES and BINDING Chapter 8

    210 CHAPTER 7. NAMES AND BINDING Chapter 8 Expressions and Evaluation Overview This chapter introduces the concept of the programming environment and the role of expressions in a program. Programs are executed in an environment which is provided by the operating system or the translator. An editor, linker, file system, and compiler form the environment in which the programmer can enter and run programs. Interac- tive language systems, such as APL, FORTH, Prolog, and Smalltalk among others, are embedded in subsystems which replace the operating system in forming the program- development environment. The top-level control structure for these subsystems is the Read-Evaluate-Write cycle. The order of computation within a program is controlled in one of three basic ways: nesting, sequencing, or signaling other processes through the shared environment or streams which are managed by the operating system. Within a program, an expression is a nest of function calls or operators that returns a value. Binary operators written between their arguments are used in infix syntax. Unary and binary operators written before a single argument or a pair of arguments are used in prefix syntax. In postfix syntax, operators (unary or binary) follow their arguments. Parse trees can be developed from expressions that include infix, prefix and postfix operators. Rules for precedence, associativity, and parenthesization determine which operands belong to which operators. The rules that define order of evaluation for elements of a function call are as follows: • Inside-out: Evaluate every argument before beginning to evaluate the function. 211 212 CHAPTER 8. EXPRESSIONS AND EVALUATION • Outside-in: Start evaluating the function body.
  • Exam 1 Review: Solutions Capture the Dragons

    Exam 1 Review: Solutions Capture the Dragons

    CSCI 1101B: Introduction to Computer Science Instructor: Prof. Harmon Exam 1 Review: Solutions Capture the Dragons Boolean Expressions 1. Of the following, which are Boolean expressions? (a)2+3 Not Boolean (b)2>3 Boolean (c) num >= 2 Boolean (d) num1 = num2 Not Boolean 2. If x = 3, and x <= y evaluates to True, what values can y have? y >= 3 3. Simplify each of the following expressions: (a) my_num or True Depends on what the value of my_num is. See rules as in #5. (b) False and "Mary" or True True (c) False and ("Mary" or True) False 4. Is x =< y the same as x <= y? No. Python only recognizes the latter. The former is invalid syntax. 5. If x = 1 and y = 2, explain the following results: (a) >>> x and y # = 2 (b) >>> x or y # = 1 Python uses lazy evaluation. • The expression x and y first evaluates x. If x is equivalent to False (or empty/zero), its value is returned. Otherwise, y is evaluated and the resulting value is returned. • The expression x or y first evaluates x. If x is equivalent to True (or non-empty/nonzero), its value is returned. Otherwise, y is evaluated and the resulting value is returned. 1 CSCI 1101B: Introduction to Computer Science Exam 1 Review: Solutions Conditionals 1. What is indentation, and how is it related to the concept of a code block? Indentation is the placement of text (to the left or right). Python uses indenta- tion to associate code into groups, or blocks. 2. What is the difference between a chained conditional and a nested conditional? Chained => if, elif, else Nested => conditionals exist (are "nested") inside each other 3.
  • Platform SDK Developer's Guide

    Platform SDK Developer's Guide

    Platform SDK Developer's Guide Platform SDK 9.0.x 3/6/2020 Table of Contents Welcome to the Developer's Guide! 4 Introductory Topics 6 Introducing the Platform SDK 7 Architecture of the Platform SDK 12 Connecting to a Server 14 Configuring Platform SDK Channel Encoding for String Values 32 Using the Warm Standby Application Block 33 Using the Application Template Application Block 42 Using the Cluster Protocol Application Block 74 Event Handling 88 Setting up Logging in Platform SDK 100 Additional Logging Features 106 Log4j2 Configuration with the Application Template Application Block 116 Advanced Platform SDK Topics 132 Using Kerberos Authentication in Platform SDK 133 Secure connections using TLS 137 Quick Start 143 TLS and the Platform SDK Commons Library 147 TLS and the Application Template Application Block 160 Configuring TLS Parameters in Configuration Manager 167 Using and Configuring Security Providers 190 OpenSSL Configuration File 201 Use Cases 208 Using and Configuring TLS Protocol Versions 211 Lazy Parsing of Message Attributes 214 Log Filtering 218 Hide or Tag Sensitive Data in Logs 230 Profiling and Performance Services 237 IPv6 Resolution 243 Managing Protocol Configuration 248 Friendly Reaction to Unsupported Messages 252 Creating Custom Protocols 258 JSON Support 267 Working with Custom Servers 276 Bidirectional Messaging 282 Hide Message Attributes in Logs 287 Resources Releasing in an Application Container 289 Transport Layer Substitution 292 Server-Specific Overviews 301 Telephony (T-Server) 302 Introduction to TLib
  • Design Patterns for Parsing Dung “Zung” Nguyen Mathias Ricken Stephen Wong Dept

    Design Patterns for Parsing Dung “Zung” Nguyen Mathias Ricken Stephen Wong Dept

    Design Patterns for Parsing Dung “Zung” Nguyen Mathias Ricken Stephen Wong Dept. of Computer Science Dept. of Computer Science Dept. of Computer Science Rice University Rice University Rice University Houston, TX 77005 Houston, TX 77005 Houston, TX 77005 +1 713-348-3835 +1 713-348-3836 +1 713-348-3814 [email protected] [email protected] [email protected] ABSTRACT be effective, they must progress normally yet quickly to cover We provide a systematic transformation of an LL(1) grammar to topics that are complex enough to make a compelling case for an object model that consists of OOP (see for instance, [2][3]). A wealth of problems in various • an object structure representing the non-terminal symbols and phases of a compiler can be appropriately modeled as object- their corresponding grammar production rules, oriented systems. However, such problems are rarely discussed at the introductory level in current computer science curricula. • a union of classes representing the terminal symbols (tokens). A quick tour of web sites and extant textbooks [4][5][6][7] seems We present a variant form of the visitor pattern and apply it to the to indicate that context-free grammars (CFG) and their related above union of token classes to model a predictive recursive topics are usually relegated to upper division courses in descent parser on the given grammar. Parsing a non-terminal is programming languages and compiler construction. Efforts have represented by a visitor to the tokens. For non-terminals that have been made to introduce object-oriented design patterns such as the more than one production rule, the corresponding visitors are composite and visitor patterns into such courses at the semantic chained together according to the chain of responsibility pattern in analysis phases but not at the syntax analysis phase [5][8].
  • Pharo by Example

    Pharo by Example

    Portland State University PDXScholar Computer Science Faculty Publications and Computer Science Presentations 2009 Pharo by Example Andrew P. Black Portland State University, [email protected] Stéphane Ducasse Oscar Nierstrasz University of Berne Damien Pollet University of Lille Damien Cassou See next page for additional authors Let us know how access to this document benefits ouy . Follow this and additional works at: http://pdxscholar.library.pdx.edu/compsci_fac Citation Details Black, Andrew, et al. Pharo by example. 2009. This Book is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. For more information, please contact [email protected]. Authors Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker This book is available at PDXScholar: http://pdxscholar.library.pdx.edu/compsci_fac/108 Pharo by Example Andrew P. Black Stéphane Ducasse Oscar Nierstrasz Damien Pollet with Damien Cassou and Marcus Denker Version of 2009-10-28 ii This book is available as a free download from http://PharoByExample.org. Copyright © 2007, 2008, 2009 by Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz and Damien Pollet. The contents of this book are protected under Creative Commons Attribution-ShareAlike 3.0 Unported license. You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).