ΜIcon Bullets on parade. Preliminary: Continuation passing style The code following a function call is wrapped up in a method - the continuation.

Slides:



Advertisements
Similar presentations
Closures & Environments CS153: Compilers Greg Morrisett.
Advertisements

Adapted from Scott, Chapter 6:: Control Flow Programming Language Pragmatics Michael L. Scott.
Control Structures Any mechanism that departs from straight-line execution: –Selection: if-statements –Multiway-selection: case statements –Unbounded iteration:
1 Programming Languages (CS 550) Lecture Summary Functional Programming and Operational Semantics for Scheme Jeremy R. Johnson.
Chapter 5 ( ) of Programming Languages by Ravi Sethi
Principles of programming languages 4: Parameter passing, Scope rules Department of Information Science and Engineering Isao Sasano.
CS 330 Programming Languages 10 / 16 / 2008 Instructor: Michael Eckmann.
Constraint Logic Programming Ryan Kinworthy. Overview Introduction Logic Programming LP as a constraint programming language Constraint Logic Programming.
Cse321, Programming Languages and Compilers 1 6/19/2015 Lecture #18, March 14, 2007 Syntax directed translations, Meanings of programs, Rules for writing.
Stacks (Revised and expanded from CIT 591). What is a stack? A stack is a Last In, First Out (LIFO) data structure Anything added to the stack goes on.
CS 201 Functions Debzani Deb.
1 Scheme Although Scheme is syntactically a simple language, it supports sophisticated modeling: higher-order functions are a powerful tool in describing.
Functional programming: LISP Originally developed for symbolic computing First interactive, interpreted language Dynamic typing: values have types, variables.
CSC321: Programming Languages1 Programming Languages Tucker and Noonan Chapter 9: Functions 9.1 Basic Terminology 9.2 Function Call and Return 9.3 Parameters.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 9 Functions It is better to have 100 functions.
CSE341: Programming Languages Lecture 11 Type Inference Dan Grossman Winter 2013.
Exceptions. Many problems in code are handled when the code is compiled, but not all Some are impossible to catch before the program is run  Must run.
 Value, Variable and Data Type  Type Conversion  Arithmetic Expression Evaluation  Scope of variable.
Ryan Chu. Arithmetic Expressions Arithmetic expressions consist of operators, operands, parentheses, and function calls. The purpose is to specify an.
Chapter 13 Recursion. Topics Simple Recursion Recursion with a Return Value Recursion with Two Base Cases Binary Search Revisited Animation Using Recursion.
CSc 453 Runtime Environments Saumya Debray The University of Arizona Tucson.
10/16/2015IT 3271 All about binding n Variables are bound (dynamically) to values n values must be stored somewhere in the memory. Memory Locations for.
Interpretation Environments and Evaluation. CS 354 Spring Translation Stages Lexical analysis (scanning) Parsing –Recognizing –Building parse tree.
Unit Testing 101 Black Box v. White Box. Definition of V&V Verification - is the product correct Validation - is it the correct product.
Dr. Philip Cannata 1 Functions and Recursion. Dr. Philip Cannata 2 10 Java (Object Oriented) ASP RDF (Horn Clause Deduction, Semantic Web) Relation Jython.
CPS120: Introduction to Computer Science Decision Making in Programs.
Functional Programming With examples in F#. Pure Functional Programming Functional programming involves evaluating expressions rather than executing commands.
Saeed Ghanbartehrani Summer 2015 Lecture Notes #5: Programming Structures IE 212: Computational Methods for Industrial Engineering.
Section 4 - Functions. All of the programs that we have studied so far have consisted of a single function, main(). However, having more than one function.
CSI 3120, Control, page 1 Control statements Simple statements Basic structured statements Sequence Selection Iteration The jump statement.
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Selection Statements Selection Switch Conditional.
Chapter 7 Selection Dept of Computer Engineering Khon Kaen University.
MT311 Java Application Development and Programming Languages Li Tak Sing( 李德成 )
CSE 425: Control Abstraction I Functions vs. Procedures It is useful to differentiate functions vs. procedures –Procedures have side effects but usually.
Copyright © 2006 The McGraw-Hill Companies, Inc. Basic Terminology Value-returning functions: –known as “non-void functions/methods” in C/C++/Java –called.
CSE 332: C++ Statements C++ Statements In C++ statements are basic units of execution –Each ends with ; (can use expressions to compute values) –Statements.
CMSC 330: Organization of Programming Languages Operational Semantics a.k.a. “WTF is Project 4, Part 3?”
Fall 2008Programming Development Techniques 1 Topic 17 Assignment, Local State, and the Environment Model of Evaluation Section 3.1 & 3.2.
CMSC 330: Organization of Programming Languages Operational Semantics.
From Conventional Languages to Prolog –What we can do in conventional languages but not in Prolog –What we can do in Prolog but not in conventional languages.
Dr. Philip Cannata 1 Functions and Recursion Programming Languages.
Announcements Assignment 2 Out Today Quiz today - so I need to shut up at 4:25 1.
4 - Conditional Control Structures CHAPTER 4. Introduction A Program is usually not limited to a linear sequence of instructions. In real life, a programme.
FUNCTIONS (C) KHAERONI, M.SI. OBJECTIVE After this topic, students will be able to understand basic concept of user defined function in C++ to declare.
Operational Semantics of Scheme
Lesson #5 Repetition and Loops.
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Spring 2017.
Functions.
Introduction to Computer Science / Procedural – 67130
Lesson #5 Repetition and Loops.
The interpreter.
Object Oriented Programming
Lesson #5 Repetition and Loops.
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Autumn 2018.
The Metacircular Evaluator
FP Foundations, Scheme In Text: Chapter 14.
Coding Concepts (Basics)
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Zach Tatlock Winter 2018.
Type & Typeclass Syntax in function
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Spring 2016.
UNIT V Run Time Environments.
Dan Grossman / Eric Mullen Autumn 2017
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Autumn 2017.
Java Programming Language
6.001 SICP Interpretation Parts of an interpreter
Lesson #5 Repetition and Loops.
Assignments and Procs w/Params
Rehearsal: Lazy Evaluation Infinite Streams in our lazy evaluator
Controlling Program Flow
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Spring 2019.
Presentation transcript:

μIcon Bullets on parade

Preliminary: Continuation passing style The code following a function call is wrapped up in a method - the continuation - and passed along as a parameter. Calculating the n-th factorial recursively In continuation passing style Actually it’s the closure we’re passing along, so this style of programming restricts our choise of language (ML/C#/Java?), leaving out e.g. C and Object Pascal. fun fac 0 = 1 | fac n = n * fac (n - 1) fun fac (k, 0) = k 1 | fac (k, n) = fac (fn x => k (n * x), n - 1) n-th factorial = fac(fn x => x, n)

Icon - A crash course I Whereas C, C++, Java and other related languages differentiate between statements and expressions, Icon has only expressions. Icon expressions may either fail or succeed, and successful expression may generate not only one, but a (not necessarily finite) sequence of results. A successful expression may produce either values or variables. (1 < 0) # failing "hi world" # generating a single value (0 to 9) # generating 0, 1, 2,..., 9 (7 | 9 | 13) # generating 7, 9, 13 (x := 7) # generating the variable x (x | y | z) # generating x, y, z e.g. every ((x | y | z) := 1)

Icon - A crash course II It's perfectly allowable for an expression to fail. Icon provides many of the well-known control structures (if-then- else, while-do, etc.), where instead of boolean values, the success or failure of an evaluation determines control flow. Failure is propagated through operators/functions, and thus the failure mechanism acts much like C#/Java exceptions. while line := read() do # read() fails on process(line) # reaching EoF while process(read()) # like above # neat isn’t it

Icon - A crash course III Expression evaluation is goal-directed, in the sense that an outer expression will resume its inner subexpressions in an attempt to succeed. Inner expressions are resumed from right to left why we use the term backtracking. write((i := (0 to 9)) & (3 < i)) # eventually succeeds, writing out 4 (7 < write(y <- (0 to 9))) # writes out " " before # eventually succeeding, generating 8

Icon - A crash course IV (a few oddities) Unlike their cousins in C/C++/Java, Icon variables are typeless. Values however are typed. Icon variables may carry any type of value, and type conversion of the variable value will be performed automatically as required. Icon variable are late bound, i.e. dereferenced only when the value is needed. Procedure arguments are passed by value, however due to the late binding of variables, dereferencing is not done until all arguments have been evaluated (arguments are evaluated from left to right, C/C++ make no such promises): fun(x := 1, x := x + 1); # calls fun with the arguments (2, 2)

μIcon All μIcon values are of integer type. Regular Icon procedures are first class citizens, and may be assigned to variables, passed as arguments, etc. μIcon procedures are not, but are similar to C functions. Only local variables are supported, global variables are not. μIcon includes only a small subset of the full set of Icon expressions. μIcon procedures have so far accepted only a single argument. Today we'll add support for multiple-argument procedures.

The inner workings of the interpreter I (data) [Griswold] “The term outcome is used to describe the result of evaluating an expression, whether it is success or failure.” [Griswold] “The term result is used collectively to include both values and variables.” | Outcome | ^ ^ | | | | | Failure | | | | Success |<>---->| Result | ^ ^ | | | | | Variable |<>---->| Store |<>---+ | | | | | | Value |< | | | int: i |

The inner workings of the interpreter II All expressions implement the Expression interface, defining a single method Eval taking as input four continuations and a run-time environment. If the expression succeeds, we'll call the success continuation cont passing along the produced result as well as a backtracking continuation, allowing an enclosing expression to ask for more results. The second argument fcont is the failure/backtracking continuation, to be called if the expression fails. public interface Expression { Outcome Eval(Cont cont, Fcont fcont, REnv env, Cont rc, Fcont rfc); }

Multiple-argument procedures I Let’s have a look at the source code (you might want to bring along a cup of coffee).

Multiple-argument procedures II

A few perverted examples The late binding of variables: Generating a new set of arguments if the body fails: procedure sum(a, b) # writes 2 to return (a + b) # standard out end procedure main () x := 0; write(sum(x, x := x + 1)) end procedure backtrack(i, j) # writes " " return 3 < write(j) # to standard out end procedure main () backtrack(x := (0 to 9), y := x) end

Concluding thoughts (highly subjective) Think twice before introducing continuations and apply with care, as the readability of your code will suffer greatly (did anyone spot the error in the report?) While the goal directed evaluation of expressions is an intriguing idea, I’ve yet to come across a problem where this brute force approach would the best answer. Honestly, I can't for the love of God see how the late dereferencing of arguments will lead to anything but trouble. I do appreciate how making failure of expressions an integrated part of the language allows for very elegant code (a kind of lightweight exceptions). Keep in mind though that you’ll only be able to appreciate the value of an answer once you know the right question…