Programming Language Principles

Slides:



Advertisements
Similar presentations
Semantics Static semantics Dynamic semantics attribute grammars
Advertisements

Adapted from Scott, Chapter 6:: Control Flow Programming Language Pragmatics Michael L. Scott.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap Overview:  Syntax and Semantics  Semantics of Expressions.
Getting started with ML ML is a functional programming language. ML is statically typed: The types of literals, values, expressions and functions in a.
COP4020 Programming Languages Expression and assignment Prof. Xin Yuan.
CSE 425: Semantic Analysis Semantic Analysis Allows rigorous specification of a program’s meaning –Lets (parts of) programming languages be proven correct.
Compiler Construction
Comp 205: Comparative Programming Languages Semantics of Imperative Programming Languages denotational semantics operational semantics logical semantics.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap  Syntax and Semantics  Semantics of Expressions 
9/27/2006Prof. Hilfinger, Lecture 141 Syntax-Directed Translation Lecture 14 (adapted from slides by R. Bodik)
ITERATIVE CONSTRUCTS: DOLIST Dolist is an iterative construct (a loop statement) consisting of a variable declaration and a body The body states what happens.
Denotational Semantics Syntax-directed approach, generalization of attribute grammars: –Define context-free abstract syntax –Specify syntactic categories.
Introduction to ML - Part 2 Kenny Zhu. What is next? ML has a rich set of structured values Tuples: (17, true, “stuff”) Records: {name = “george”, age.
Introduction to ML Last time: Basics: integers, Booleans, tuples,... simple functions introduction to data types This time, we continue writing an evaluator.
Loops – While, Do, For Repetition Statements Introduction to Arrays
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Denotational Semantics ICS.
Cs164 Prof. Bodik, Fall Symbol Tables and Static Checks Lecture 14.
CONTROL STATEMENTS Lakhbir Singh(Lect.IT) S.R.S.G.P.C.G. Ludhiana.
Programming Language Principles Lecture 26 Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Denotational Semantics.
Principles of Programming Languages Lecture 1 Slides by Daniel Deutch, based on lecture notes by Prof. Mira Balaban.
CS 280 Data Structures Professor John Peterson. How Does Parsing Work? You need to know where to start (“statement”) This grammar is constructed so that.
Interpretation Environments and Evaluation. CS 354 Spring Translation Stages Lexical analysis (scanning) Parsing –Recognizing –Building parse tree.
Formal Semantics for Rule-Based Systems 報告者:黃怡玲 指導教授:丁德榮.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
0 Odds and Ends in Haskell: Folding, I/O, and Functors Adapted from material by Miran Lipovaca.
Dr. Muhammed Al-MulhemICS (Denotational Semantics)
Standardizing RPAL AST’s Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 10.
Writing RPAL Programs Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture 13.
The RPAL Functional Language Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Concepts Lecture 12.
An Attribute Grammar for Tiny Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 18.
Programming Language Principles Lecture 32 Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Course Summary.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Denotational Semantics.
CMSC 330: Organization of Programming Languages Operational Semantics.
Copyright 2006 Addison-Wesley Brief Version of Starting Out with C++ Chapter 5 Looping.
Overview of Compilation Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 2.
Programming Languages Concepts Chapter 1: Programming Languages Concepts Lecture # 4.
OPERATORS IN C CHAPTER 3. Expressions can be built up from literals, variables and operators. The operators define how the variables and literals in the.
Building AST's for RPAL Programs
Expressions and Assignment
Tuples Module 11.1 COP4020 – Programming Language Concepts Dr. Manuel E. Bermudez.
Python: Control Structures
Chapter 2 Assignment and Interactive Input
An Attribute Grammar for Tiny
Chapter 5: Loops and Files.
Introduction to RPAL Module 10.1 COP4020 – Programming Language Concepts Dr. Manuel E. Bermudez.
Chapter 5: Looping Copyright © 2010 Pearson Education, Inc. Publishing as Pearson Addison-Wesley.
Programming Language Principles
Programming Language Concepts
ENERGY 211 / CME 211 Lecture 15 October 22, 2008.
The Metacircular Evaluator
CSCI 3328 Object Oriented Programming in C# Chapter 4: C# Control Statement – Part I – Exercises UTPA – Fall 2012 This set of slides is revised from lecture.
Logics for Data and Knowledge Representation
The University of Texas – Pan American
CSE 341 Section 5 Winter 2018.
Programming Language Principles
The Metacircular Evaluator (Continued)
Building AST's for RPAL Programs
Logics for Data and Knowledge Representation
Programming Language Principles
The RPAL Functional Language
Recursion and Rpal’s synTax
Compiler Construction
6.001 SICP Interpretation Parts of an interpreter
The Selection Structure
Using C++ Arithmetic Operators and Control Structures
Introduction to Bash Programming, part 3
Compiler Construction
REPETITION Why Repetition?
Presentation transcript:

Programming Language Principles Extending Tiny Programming Language Principles Lecture 27 Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida

Tiny’s Denotational Semantics in RPAL let EQ x y = Istruthvalue x & Istruthvalue y -> (x & y) or (not x & not y) | Isstring x & Isstring y or Isinteger x & Isinteger y -> x eq y | false in let COMP f g x = let R = f x in R @EQ 'error' -> 'error' | g R

Tiny’s Denotational Semantics in RPAL let PIPE x f = x @EQ 'error' -> 'error' | (f x) in let Return v s = (v,s) let Check Dom (v,s) = Dom eq 'Num' -> Isinteger v -> (v,s) | 'error' | Dom eq 'Bool' -> Istruthvalue v -> (v,s) | 'error' | 'error'

Tiny’s Denotational Semantics in RPAL let Dummy s = s in let Cond F1 F2 (v,s) = s @PIPE (v -> F1 | F2) let Replace m i v x = x @EQ i -> v | m x let Head i = i 1 let Tail T = rtail T (Order T) where rec rtail T N = N eq 1 -> nil | (rtail T (N-1) aug (T N))

Tiny’s Denotational Semantics in RPAL let rec EE E (m,i,o) = Isinteger E -> Return E (m,i,o) | Isstring E -> ( E eq 'true' -> Return true (m,i,o) | E eq 'false' -> Return false (m,i,o) | E eq 'read' -> Null i -> 'error' | (Head i,(m,Tail i,o)) | (let R = m E in R @EQ 'undef' -> 'error' | (R,(m,i,o)) )

Tiny’s Denotational Semantics in RPAL | Istuple E -> ( (E 1) @EQ 'not' -> (m,i,o) @PIPE EE(E 2) @PIPE (Check 'Bool') @PIPE (fn(v,s).(not v,s))

Tiny’s Denotational Semantics in RPAL | (E 1) @EQ '<=' -> (m,i,o) @PIPE EE(E 2) @PIPE (Check 'Num') @PIPE (fn(v1,s1). s1 @PIPE EE(E 3) @PIPE (fn(v2,s2).(v1 le v2,s2)) )

Tiny’s Denotational Semantics in RPAL | (E 1) @EQ '+' -> (m,i,o) @PIPE EE(E 2) @PIPE (Check 'Num') @PIPE (fn(v1,s1). S1 @PIPE EE(E 3) @PIPE (fn(v2,s2).(v1 + v2,s2)) ) | 'error' // not 'not', '<=', '+' | 'error' // not a tuple in

Tiny’s Denotational Semantics in RPAL let rec CC C s = not (Istuple C) -> 'error' |(C 1) @EQ ':=' -> s @PIPE EE (C 3) @PIPE (fn(v,s). (Replace (s 1) (C 2) v,s 2,s 3)) |(C 1) @EQ 'print' -> s @PIPE EE (C 2) (s 1,s 2,s 3 aug v))

Tiny’s Denotational Semantics in RPAL | (C 1) @EQ 'if' -> s @PIPE EE (C 2) @PIPE (Check 'Bool') @PIPE (Cond (CC(C 3)) (CC(C 4))) | (C 1) @EQ 'while' @PIPE Cond (CC(';',C 3,C)) Dummy

Tiny’s Denotational Semantics in RPAL |(C 1) @EQ ';' -> s @PIPE CC (C 2) @PIPE CC (C 3) | 'error' // not ':=', 'if', ... in let PP P = not (Istuple P) -> (fn i. 'error') | not ((P 1) @EQ 'program') -> (fn i. 'error') | ((fn i. CC (P 2) ((fn i.'undef'),i,nil) //start state! ) @COMP (fn s.(s 3)) )

Tiny’s Denotational Semantics in RPAL Print ( PP ('program', // test program (';', (':=', 'x',3), ('print', 'x') ) ) (nil aug 3) // the input Whew ! Now, RUN IT !!

Tiny’s Denotational Semantics in RPAL Executable semantic specification of Tiny. Add a parser, and voilà ... Tiny is implemented ! Could even write the parser in RPAL ...  Inefficient, but who cares ... 'error' (and others) should probably be '<error>', so we allow those as variable names in Tiny. Subject to change: Alter order of evaluation of operands. Allow comparison of booleans.

Extending Tiny First, add more comparison operators, and lots of arithmetic operators (easy). Example: EE[<- E1 E2>] = EE[E1] o (Check Num) o (λ(v1,s1). s1 => EE[E2] => (Check Num) => (λ(v2,s2).(v1 - v2,s2) )

Extending Tiny Let’s add the '=' comparison operator. Allow for Num and Bool. This allows type mixing ! EE[<= E1 E2>] = EE[E1] o (Check Num) o (λ(v1,s1). s1 => EE[E2] => (Check Num) => (λ(v2,s2).(v1 eq v2,s2) )

Add Conditional Expression Need a new auxiliary function: Econd. ECond: (State → Val x State) → (State → Val x State) → (Val x State) Econd = λEF1. λEF2. λ(v,s). s => (v → EF1 | EF2) EE[<cond E1 E2 E3>] = EE[E1] o (Check Bool) o (Econd EE[E2] EE[E3])

Add prefix auto-increment operator EE[<++ I>] = | EE[I] o (Check Num) (λ(v,(m,i,o)). v eq  → error | (v+1, (Replace m I (v+1)), i, o) ) For postfix (n++), change this to v !

Adding the one-armed ‘if’ to Tiny CC[<if E C>] = EE[E] o (Check Bool) o (Cond CC[C] Dummy) Of course, for most of these, the syntactic domains need to be updated.

Adding a ‘repeat’ statement to Tiny CC[<repeat C E>] = CC[C] o EE[E] o (Check Bool) o (Cond Dummy (CC[<repeat C E>])) or better yet, CC[C] o CC[<while <not E> C>]

Adding a read statement to Tiny CC[<read I>] = | λ(m,i,o). Null i → error | (Replace m I (Head i), Tail i, o) Would need to remove the ‘read’ expression.

Adding the Pascal ‘for’ loop to Tiny CC[<for I F L C>] = EE[L] o (Check Num) o (λ(l,s). S => EE[F] => (Check Num) => (λ(f,(m,i,o)). (Replace m I f, i, o) => CC[<while < ≤ I l> <; C <:= I <+ I 1>>> ] ) ) o (λ(m,i,o). (Replace m I , i, o)) Yuck. Can’t enforce lots of rules.

Adding the C ‘for’ loop to Tiny CC[<for F E I C>] = CC[F] o CC[<while E <; C I>>] or CC[<; F <while E <; C I>>] Remarkably simple, eh ? Of course, Tiny has no continue statement to get in the way. We assume default values have been added for any missing parts, e.g. true for E.

Adding a ‘case’ statement to Tiny CC[<case E CC1 ... CCn >] = EE[E] o (Check Num) o C_CC[CC1] ... C_CC[CCn] o (λ(v,s).s) Need a new syntactic domain, for case-clauses: C_C = <c_c n C> Also, a new semantic function to process them: C_CC: C_C → (Val x State) → (Val x State)

Adding a ‘case’ statement to Tiny To process one case clause: C_CC[<c_c n C>] = λ(v,s). v eq  → (v,s) | v ne n → (v,s) | ( , s => CC[C]) Aborts all subsequent case clauses. To process them all, change this to v !

Remarks on Denotational Semantics Exercise: implement these in RPAL ! (see ‘medium’ on website) Can this be done for “real” programming languages ? Yes, but ... We now have three formalisms for specifying the semantics of programming languages: Operational (RPAL) Attribute grammars (Tiny) Denotational (Tiny)

Remarks on Semantic Specifications Remember, parsing was *easy*  Reason: one formalism (CFG’s) good for everyone: Language user. Language implementer. Language designer. Not so in the world of semantics.

Remarks on Semantic Specifications User Designer Implementer F E T G Operational Denotational Attribute Grammar E – Excellent, G – Good F – Fair, T - Terrible

Programming Language Principles Extending Tiny Programming Language Principles Lecture 27 Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida