Programming Language PrinciplesLecture 27

Prepared byManuel E. Bermúdez, Ph.D.

Associate ProfessorUniversity of Florida

Extending Tiny

Tiny’s Denotational Semantics in RPALlet 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 | falseinlet COMP f g x = let R = f x in R @EQ 'error' -> 'error' | g Rin

Tiny’s Denotational Semantics in RPAL

let PIPE x f = x @EQ 'error' -> 'error' | (f x)inlet Return v s = (v,s)in

let Check Dom (v,s) = Dom eq 'Num' -> Isinteger v -> (v,s) | 'error'

| Dom eq 'Bool' -> Istruthvalue v -> (v,s) | 'error'

| 'error'in

Tiny’s Denotational Semantics in RPAL

let Dummy s = sinlet Cond F1 F2 (v,s) = s @PIPE (v -> F1 | F2)inlet Replace m i v x = x @EQ i -> v | m xinlet Head i = i 1inlet Tail T = rtail T (Order T)where rec rtail T N =

N eq 1 -> nil | (rtail T (N-1) aug (T N))in

Tiny’s Denotational Semantics in RPALlet 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 (Check 'Num') @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 (Check 'Num') @PIPE (fn(v2,s2).(v1 + v2,s2)) ) | 'error' // not 'not', '<=', '+' )| 'error' // not a tuplein

Tiny’s Denotational Semantics in RPALlet 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) @PIPE (fn(v,s).

(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' -> s @PIPE EE (C 2) @PIPE (Check 'Bool')

@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', ...inlet 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)) )in

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 ExpressionNeed a new auxiliary function: Econd.ECond: (State → Val x State) → (State → Val x 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[E1] EE[E2])

Add prefix auto-increment operatorEE[<++ 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[<repeat C E>] =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 l, i, o) => CC[<while < ≤ I f> <; 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 TinyCC[<case E CC1 ... CCn >] =

EE[E] o (Check Num) oC_CC[CC1] ... C_CC[CCn]

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

F F ET E GF G E

User Designer ImplementerOperational

DenotationalAttribute Grammar

E – Excellent, G – GoodF – Fair, T - Terrible

Programming Language PrinciplesLecture 27

Prepared byManuel E. Bermúdez, Ph.D.

Associate ProfessorUniversity of Florida

Extending Tiny