CS 251: Programming Languages Fall 2015 ML Summary, Part 5
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
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. -
Open WATCOM Programmer's Guide
this document downloaded from... Use of this document the wings of subject to the terms and conditions as flight in an age stated on the website. of adventure for more downloads visit our other sites Positive Infinity and vulcanhammer.net chet-aero.com Watcom FORTRAN 77 Programmer's Guide Version 1.8 Notice of Copyright Copyright 2002-2008 the Open Watcom Contributors. Portions Copyright 1984-2002 Sybase, Inc. and its subsidiaries. All rights reserved. Any part of this publication may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without the prior written permission of anyone. For more information please visit http://www.openwatcom.org/ Portions of this manual are reprinted with permission from Tenberry Software, Inc. ii Preface The Watcom FORTRAN 77 Programmer's Guide includes the following major components: · DOS Programming Guide · The DOS/4GW DOS Extender · Windows 3.x Programming Guide · Windows NT Programming Guide · OS/2 Programming Guide · Novell NLM Programming Guide · Mixed Language Programming · Common Problems Acknowledgements This book was produced with the Watcom GML electronic publishing system, a software tool developed by WATCOM. In this system, writers use an ASCII text editor to create source files containing text annotated with tags. These tags label the structural elements of the document, such as chapters, sections, paragraphs, and lists. The Watcom GML software, which runs on a variety of operating systems, interprets the tags to format the text into a form such as you see here. Writers can produce output for a variety of printers, including laser printers, using separately specified layout directives for such things as font selection, column width and height, number of columns, etc. -
COMPILING FUNCTIONAL PROGRAMMING CONSTRUCTS to a LOGIC ENGINE by Harvey Abramson and Peter Ludemann Technical Report 86-24 November 1986
COMPILING FUNCTIONAL PROGRAMMING CONSTRUCTS TO A LOGIC ENGINE by Harvey Abramson and Peter Ludemann Technical Report 86-24 November 1986 Compiling Functional Programming Constructs to a Logic Engine Harvey Abramson t and Peter Ltidemann:I: Department of Computer Science University of British Columbia Vancouver, B.C., Canada V6T 1W5 Copyright © 1986 Abstract In this paper we consider how various constructs used in functional programming can be efficiently translated to code for a Prolog engine (designed by Ltidemann) similar in spirit but not identical to the Warren machine. It turns out that this Prolog engine which contains a delay mechanism designed to permit co routining and sound implementation of negation is sufficient to handle all common functional programming constructs; indeed, such a machine has about the same efficiency as a machine designed specifically for a functional programming language. This machine has been fully implemented. t Present address: Department of Computer Science, Bristol University, Bristol, England . f Present address: IBM Canada Ltd., 1 Park Centre, 895 Don Mills Road, North York, Ontario, Canada M3C 1W3 The proposals for combining the two paradigms Compiling Functional Programming have been roughly classified in [BoGi86] as being Constructs to a Logic Engine either functional plus logic or logic plus functional. Harvey Abramson t and Peter Ltidemanni In the former approach, invertibility, nondeterminism Department of Computer Science and unification are added to some higher order functional language; in the latter approach, first-order University of British Columbia functions are added to a first-order logic with an Vancouver, B.C., Canada V6T lWS equality theory. We do not take any position as to Copyright© 1986 which approach is best, but since a logic machine already deals with unification, nondeterminism and invertibility, we have taken, from an implementation Abstract viewpoint, the logic plus functional approach. -
Parameter Passing, Generics, Exceptions
Lecture 9: Parameter Passing, Generics and Polymorphism, Exceptions COMP 524 Programming Language Concepts Stephen Olivier February 12, 2008 Based on notes by A. Block, N. Fisher, F. Hernandez-Campos, and D. Stotts The University of North Carolina at Chapel Hill Parameter Passing •Pass-by-value: Input parameter •Pass-by-result: Output parameter •Pass-by-value-result: Input/output parameter •Pass-by-reference: Input/output parameter, no copy •Pass-by-name: Effectively textual substitution The University of North Carolina at Chapel Hill 2 Pass-by-value int m=8, i=5; foo(m); print m; # print 8 proc foo(int b){ b = b+5; } The University of North Carolina at Chapel Hill 3 Pass-by-reference int m=8; foo(m); print m; # print 13 proc foo(int b){ b = b+5; } The University of North Carolina at Chapel Hill 4 Pass-by-value-result int m=8; foo(m); print m; # print 13 proc foo(int b){ b = b+5; } The University of North Carolina at Chapel Hill 5 Pass-by-name •Arguments passed by name are re-evaluated in the caller’s referencing environment every time they are used. •They are implemented using a hidden-subroutine, known as a thunk. •This is a costly parameter passing mechanism. •Think of it as an in-line substitution (subroutine code put in-line at point of call, with parameters substituted). •Or, actual parameters substituted textually in the subroutine body for the formulas. The University of North Carolina at Chapel Hill 6 Pass-by-name array A[1..100] of int; array A[1..100] of int; int i=5; int i=5; foo(A[i], i); foo(A[i]); print A[i]; #print A[6]=7 -
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 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
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. -
Programming Languages
◦ ◦◦◦ TECHNISCHE UNIVERSITAT¨ MUNCHEN¨ ◦◦◦◦ ◦ ◦ ◦◦◦ ◦◦◦◦ ¨ ¨ ◦ ◦◦ FAKULTAT FUR INFORMATIK Programming Languages Multiple Inheritance Dr. Axel Simon and Dr. Michael Petter Winter term 2012 Multiple Inheritance 1 / 29 Outline Inheritance Principles 1 Interface Inheritance 2 Implementation Inheritance 3 Liskov Substition Principle and Shapes C++ Object Heap Layout 1 Basics 2 Single-Inheritance Excursion: Linearization 3 Virtual Methods 1 Ambiguous common parents 2 Principles of Linearization C++ Multiple Parents Heap Layout 3 Linearization algorithm 1 Multiple-Inheritance 2 Virtual Methods 3 Common Parents Discussion & Learning Outcomes Multiple Inheritance 2 / 29 “Wouldn’t it be nice to inherit from several parents?” Multiple Inheritance Inheritance Principles 3 / 29 Interface vs. Implementation inheritance The classic motivation for inheritance is implementation inheritance Code reusage Child specializes parents, replacing particular methods with custom ones Parent acts as library of common behaviours Implemented in languages like C++ or Lisp Code sharing in interface inheritance inverts this relation Behaviour contract Child provides methods, with signatures predetermined by the parent Parent acts as generic code frame with room for customization Implemented in languages like Java or C# Multiple Inheritance Inheritance Principles 4 / 29 Interface Inheritance DropDownList refresh() ActionObserver MyDDL changed() changed() Multiple Inheritance Inheritance Principles 5 / 29 Implementation inheritance PowerShovel FrontLoader actuate() actuate() -
Top Functional Programming Languages Based on Sentiment Analysis 2021 11
POWERED BY: TOP FUNCTIONAL PROGRAMMING LANGUAGES BASED ON SENTIMENT ANALYSIS 2021 Functional Programming helps companies build software that is scalable, and less prone to bugs, which means that software is more reliable and future-proof. It gives developers the opportunity to write code that is clean, elegant, and powerful. Functional Programming is used in demanding industries like eCommerce or streaming services in companies such as Zalando, Netflix, or Airbnb. Developers that work with Functional Programming languages are among the highest paid in the business. I personally fell in love with Functional Programming in Scala, and that’s why Scalac was born. I wanted to encourage both companies, and developers to expect more from their applications, and Scala was the perfect answer, especially for Big Data, Blockchain, and FinTech solutions. I’m glad that my marketing and tech team picked this topic, to prepare the report that is focused on sentiment - because that is what really drives people. All of us want to build effective applications that will help businesses succeed - but still... We want to have some fun along the way, and I believe that the Functional Programming paradigm gives developers exactly that - fun, and a chance to clearly express themselves solving complex challenges in an elegant code. LUKASZ KUCZERA, CEO AT SCALAC 01 Table of contents Introduction 03 What Is Functional Programming? 04 Big Data and the WHY behind the idea of functional programming. 04 Functional Programming Languages Ranking 05 Methodology 06 Brand24 -
CS1101S Studio Session Week 11: Stream
Welcome CS1101S Studio Session Week 11: Stream Niu Yunpeng [email protected] October 30, 2018 Niu Yunpeng CS1101S Studio Week 11 October 30, 2018 1 / 27 Overview 1 Lazy evaluation Computational model Function application 2 Stream Delayed evaluation Stream programming Niu Yunpeng CS1101S Studio Week 11 October 30, 2018 2 / 27 Lazy Evaluation Computational model Computational model is a useful guideline for us to understand how the interpreter works. Computational model may vary depending on programming language and the runtime system used. In CS1101S, we introduce two computational models: substitution model and environment model. What to expect In the coming weeks, these two models will still be valid. Niu Yunpeng CS1101S Studio Week 11 October 30, 2018 3 / 27 Lazy Evaluation Substitution model For stateless programming only: Evaluate all actual arguments; Replace all formal parameters with their actual arguments; Apply each statement in the function body (and get the return value); Repeat the first 3 steps until done. Niu Yunpeng CS1101S Studio Week 11 October 30, 2018 4 / 27 Lazy Evaluation Environment model For stateful programming: Each frame contains a series of bindings of names and values. The value of a variable depends on its environment, a sequence of frames up to the global frame. Each function call will create a new frame and extend its enclosing environment. Niu Yunpeng CS1101S Studio Week 11 October 30, 2018 5 / 27 Lazy Evaluation Function in JavaScript Function in JavaScript is a first-class citizen (object). They have a call method. The call method is triggered when this function is applied. Function application When a function is applied, “this” is prepanded to the list of parameters. -
Subroutines and Control Abstraction8 8.3.2 Call by Name
Subroutines and Control Abstraction8 8.3.2 Call by Name Call by name implements the normal-order argument evaluation described in Section 6.6.2. A call-by-name parameter is re-evaluated in the caller’s referencing environment every time it is used. The effect is as if the called routine had been textually expanded at the point of call, with the actual parameter (which may be a complicated expression) replacing every occurrence of the formal parameter. To avoid the usual problems with macro parameters, the “expansion” is defined to include parentheses around the replaced parameter wherever syntactically valid, and to make “suitable systematic changes” to the names of any formal parame- ters or local identifiers that share the same name, so that their meanings never conflict [NBB+63, p. 12]. Call by name is the default in Algol 60; call by value is available as an alternative. In Simula call by value is the default; call by name is the alternative. Toimplement call by name,Algol 60 implementations pass a hidden subroutine that evaluates the actual parameter in the caller’s referencing environment. The hidden routine is usually called a thunk.2 In most cases thunks are trivial. If an actual parameter is a variable name, for example, the thunk simply reads the EXAMPLE 8.68 variable from memory. In some cases, however, a thunk can be elaborate. Perhaps Jensen’s device the most famous occurs in what is known as Jensen’s device, named after Jørn Jensen [Rut67]. The idea is to pass to a subroutine both a built-up expression and one or more of the variables used in the expression. -
Design, Semantics and Implementation of the Ptolemy
Computer Science Technical Reports Computer Science Summer 7-31-2015 Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified yT ped Events Hridesh Rajan Iowa State University, [email protected] Gary T. Leavens University of Central Florida Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons Recommended Citation Rajan, Hridesh and Leavens, Gary T., "Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified Typed Events" (2015). Computer Science Technical Reports. 376. http://lib.dr.iastate.edu/cs_techreports/376 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Design, Semantics and Implementation of the Ptolemy Programming Language: A Language with Quantified yT ped Events Abstract Implicit invocation (II) and aspect-oriented (AO) languages provide software designers with related but distinct mechanisms and strategies for decomposing programs into modules and composing modules into systems. II languages have explicitly announced events that run registered observer methods. AO languages have implicitly announced events that run method-like but more powerful advice. A limitation of II languages is their inability to refer to a large set of events succinctly. They also lack the expressive power of AO advice. Limitations of AO languages include potentially fragile dependence on syntactic structure that may hurt maintainability, and limits on the available set of implicit events and the reflective contextual information available.