Practical Techniques for Language Design and Prototyping

1
Practical Techniques for Language Design and
Prototyping

• Mark-Oliver Stehr
• University of Illinois at Urbana-Champaign
• Carolyn Talcott
• SRI International
• Schloss Dagstuhl, February 2005

2
Overview

• Motivation
• Lack of Foundations for Global Computing
• Lack of Tools to support Abstract Language Design
• Approach
• Technique to Represent Syntax (Explicit
  Substitutions)
• Theory to Represent Semantics (Felleisen-style)
• Executable Logical Framework (Rewriting Logic)
• Implementation and Tools (Maude)
• Examples related to Global Computing
• A Service-Based Packet Language for Active
  Networks
• A Core Language for Object-Oriented Programming
• Further Applications and Outlook

3
Motivation

• Global Computing Challenges
• interplay between different languages and
  protocols
• is necessarily heterogeneous
• highly concurrent and nondeterministic
• different communication/coordination paradigms
• key ideas often hidden in technical details

4
Representing Syntax

• Algebraic signature with
• distinguished sort of identifiers, and
• specification of binding structure
• Distinguish between
• binding occurences of names (e.g. as X in Lam X
  M)
• referencing occurences of names (written Xi)
• Notation Xi means the X-binder that we reach
  after skipping i-binders on the way up
• Example ((Lam x (Lam x (x0 x1)) ) x0)
• Generalizes de Bruijn indices
• Equivalent to Berklings notation for ?-calculus
• User-friendly thanks to the dimension of names

op _ _ Trm Trm -gt Trm op Lam _ _ Id Trm -gt
Trm op __ Id Nat -gt Trm
5
CINNI - Lambda

• Generalizes Lescannes ?? based on de Bruijn
  indices
• Properties Confluent and strongly normalizing

6
Sample Reduction

• Note that the original x0 has become x1 to
  maintain its reference to an external binding.
• Note also In spite of the use of names, no need
  for alpha-conversion.

7
Representing Semantics

• We use a syntax-based approach that goes back to
  Felleisen and is often referred to as
  Evaluation-Context Semantics
• The underlying idea is simple
• Reducible expressions ex can be decomposed into
• a reduction context cx? and
• a redex rex
• such that ex cxrex.
• A small step reduction relation is defined
  directly on expressions of the object language,
  using a quantification over reduction contexts
• Typical rule cx(Lam x ex) val -gt
  cxexx/val
• Deterministic and nondeterministic languages
• Deterministic languages unique decomposition

8
Felleisen-Style Semantics

• Typical rule cx(Lam x ex) val -gt
  cxexx/val
• Different from SOS, because reduction relation is
  not defined inductively over the structure of
  expressions
• A reduction context can be seen as a syntactic
  representation of the current continuation
• Hence, closely related to abstract machines
  (SECD, SEK, etc.), but more abstract because
• it works directly on expressions in the original
  syntax, and
• algorithm to find the decomposition not fixed
• Two Problems
• How to represent it in a first-order framework ?
• How to achieve executablity ?

9
Executable Felleisen-style Semantics

• Typical Rule cx(Lam x ex) val -gt
  cxexx/val

cx
cx
red
contr

• Problem Not a first-order rewrite rule, because
  the distance between red and the root is
  unbounded
• Solution Perform rewriting on decomposed form

cx
cx
cx
cx
red
contr
10
Executable Felleisen-style Semantics

• Typical Rule cx(Lam x ex) val -gt
  cxexx/val

cx
cx
cx
cx
red
contr

• We need
• first-order representation of contexts
• explicit representation of decomposition
• a specification of admissible decompositions
• control rules that find such decompositions
• reduction rules that contract the redex

11
Executable Felleisen-style Semantics

• Typical Rule cx(Lam x ex) val -gt
  cxexx/val

cx
cx
cx
cx
red
contr

• Two different notions of substitution involved
• cxex denotes textual substitution
• sometimes called hole filling or metavariable
  substitution
• straightforward to formulate using first-order
  equations
• exx/val denotes capture-free substitution
• to make it first-order we write x val ex and
  work modulo CINNI

12
Sample Language
imperative call-by-value ?-calculus with
recursion and exceptions

• op __ String Nat -gt Ex .
• op _ _ Ex ExList -gt Ex.
• op __ Ex Ex -gt Ex.
• op If_Then_Else_ Ex Ex Ex -gt Ex .
• op Let___ IdList ExList Ex -gt Ex.
• op LetRec___ IdList ExList Ex -gt Ex.
• op Lam__ IdList Ex -gt Ex .
• op Try_Catch__ Ex Id Ex -gt Ex .
• op Throw_ Ex -gt Ex .

Arithmetic, Pairs, Lists
13
Reduction State

• Reduction state
• RedState(cx,ex)
• Value expressions
• (Int 0)
• (Cons (Int 0, Cons (Int 1, Nil)))
• (Lam x (x0 x0))
• Non-Value (i.e. redex) expressions
• (Hd (Cons (Int 1, Nil)))
• (Let "n" (Int 2) (Plus ("n"0 "n"0)))
• Reduction contexts
• (Let "n" ? (Plus ("n"0 "n"0)))
• Hole filling
• lt? (Int 2)gt(Let "n" ? (Plus ("n"0
  "n"0)))
• Capture-free substitutions (CINNI)
• "n" (Int 2) (Plus ("n"0 "n"0)))

14
Expression Decomposition

• An expression is a value or uniquely decomposes
  into a reduction context filled with a redex
• (Let "n" (If (Equal n0 (Int 0)) Then
  (Int 1) Else (Int 2))
• (Plus ("n"0 "n"0)))
• lt? (If (Equal n0 (Int 0)) Then (Int 1)
  Else (Int 2)) gt
• (Let "n" ? (Plus ("n"0 "n"0))) gt
• lt? (Equal n0 (Int 0)) gt
• (lt? (If ? Then (Int 1) Else (Int 2)) gt
• (Let "n" ? (Plus ("n"0 "n"0))) gt)

15
Rules for ?
cx
cx
cx
cx

• Control Rules
• rl RedState(cx, (val nval))
• gt RedState(lt ? (val ?)) gt cx, nval) .
• rl RedState(cx, val)
• gt RedState(?, lt ? val gt cx) .
• Reduction Rule
• rl RedState(cx, ((Lam x ex) val))
• gt RedState(cx, x val ex) .

red
nval
nval
val
red
val
cx
cx
cx
cx
val
val
val
cx
cx
cx
cx
red
contr
16
Rules for ? (Optimized)
cx
cx
cx
cx
red

• Control Rules
• rl RedState(cx, (val nval))
• gt RedState( ltlt ? (val ?)) gtgt cx , nval)
  . lazy substitution !
• rl RedState( ltlt ? cx gtgt cx , val) lazy
  substitution !
• gt RedState(cx', lt ? val gt cx) . eager
  substitution !
• Same idea as Refocussing in Danvy Nielsen
  2001

nval
nval
val
red
val
cx
cx
cx
cx
cx
val
cx
cx
val
17
Reduction Rules for Exceptions

• Non error case
• rl RedState(cx, (Try val Catch id ex'))
• gt RedState(cx, val) .
• Error case
• rl RedState(cx, (Try (Throw eval) Catch id
  ex'))
• gt RedState(cx, id eval ex') .
• rl RedState(cx, ((Throw eval) exl))
• gt RedState(cx, (Throw eval)) .
• rl RedState(cx, (val (vall,(Throw eval),exl)))
• gt RedState(cx, (Throw eval)) .
• rl RedState(cx, (Throw eval) ex)
• gt RedState(cx, (Throw eval)) .

18

• Application I
• A Service-based Packet Language
• for Active Networks

19
What are Active Networks?

• Wired, wireless or hybrid networks that support
  active packets
• Active packets carry code that executes on
  routers
• gather information
• modify node state
• configure router
• Executing active packets allows for
• optimizations and adaptation to changing
  requirements
• extensions of current protocols
• dynamic installation of fundamentally new
  protocols
• Examples of active packet services
• data caching
• multicast congestion control and repair services
• QoS-based route discovery

20
PLAN Packet Language for Active Networks

• Developed in the DARPA-funded Switchware Project
  at UPenn Nettles, Gunter et. al. 1998
• Program is a set of packets executing in the
  network
• Features
• functional call-by-value language with
  side-effects
• ML-style syntax, but first-order except for some
  builtin functions
• usual functional data types network specific
  types
• computational and communication resource limited
• communication primitives based on remotely
  executed function call in the context of its
  original scope (possibly recursive)
• service packages for interacting with nodes
• xPLAN
• extension with simpler syntax
• imperative call-by-value ?-calculus as a basis
• general-purpose language for mobile applications

21
A Sample PLAN Program
recursive distributed route finding

• Forward search recursively sends active (!) find
  packets to all neighbors until the destination
  is reached.
• At each node a backpointer, the address of the
  exit interface of the previous node, is stored in
  the local data store.
• From the destination node a goback packet is sent
  that follows the path given by the stored
  addresses back to the source, accumulating a
  route on the way.

22
Find program as a Maude term

• (LetRec "goback" Lam("k","route")
  (TKey,(TList TAddr)) ...
• (LetRec
• "find" Lam("dest","previous","k)
  (TAddr,TAddr,TKey)
• (If (Exists ((String ""),"k"0))
• Then Dummy
• Else ((Put ((String ""),"k"0,
  "previous"0, (Int 200)))
• (If (ThisHostIs "dest"0)
• Then ("goback"0 ("k"0,Nil))
• Else (
• (Let "neighbors" (GetNeighbors
  empty-exl)
• (Let "srcdev" (GetSrcDev
  empty-exl)
• (Let "childrb" ... divide up
  rb
• (Let "sendchild" ... emit a find
  packet ...
• (Foldr ("sendchild"0,"neighbors"0,D
  ummy)) ))))) )))
• ("find"0 ((Addr find-dest), (GetSource
  empty-exl), (GenerateKey empty-exl))) )) .

23
Function SendChild

• Letsendchild"
• Lam ("n","u") ((TPair TAddr TAddr),TUnit)
  
• (OnNeighbor
• ((Chunk ("find"0, ("dest"0,(Snd
  "n"0),"k"0))),
• (Fst "n"0), neighbor dev
• "childrb"0, resource bound
• (Snd "n"0))) out dev

24
Semantics - Overview

• PLAN -gt xPLAN
• representation mapping essentially an inclusion
• PLAN well-typed, all recursive calls inside
  chunks
• xPLAN Semantics
• Reduction Machine (Felleisen-style)
• Network model (Multiset rewriting)
• Resident Data and Network Services

PLAN
xPLAN
25
Network and Execution Model

• A network configuration is a multiset containing
  
• Nodes
• - Node(loc,devs,nbrs,rt)
• Packets in transit
• - Packet(nhop,fdest,orign,ssn,rb,rf,val,vall)
  
• Processes
• - Process(loc,orign,ardev,ssn,rb,
  RedState(cx,ex) )
• Data stores
• - Data(loc,...DataItem(id,key,val,ttl)...)
• A key counter
• - FreshKey(n)

26
Sample Network

• example-topology
• FreshKey(10)
• Node(loc("l0"), (addr("i0"),addr("a0")),
• ((addr("a0") gtgt addr("a1"))),
• ((addr("a1") via (addr("a0") gtgt
  addr("a1"))),
• (addr("b1") via (addr("a0") gtgt
  addr("a1"))),
• ...))
• Data(loc("l0"), empty-dil)
• Node(loc("l1"), (addr("a1"),addr("b1"),addr(
  "c1")),
• ((addr("a1") gtgt addr("a0")),
• (addr("b1") gtgt addr("b2")),
• (addr("c1") gtgt addr("c3"))),
• ((addr("a0") via (addr("a1") gtgt
  addr("a0"))),
• (addr("b2") via (addr("b1") gtgt
  addr("b2"))),
• ...))
• Data(loc("l1"), empty-dil)
• ... .

27
Packet Emission Rule

• crl Node(l,devs,nbrs,rt)
• Process(l, orign, ardev, ssn, rb,
• RedState(cx, (OnNeighbor ((Chunk (val,vall)
  ),
• (Addr dest),(Int int),(Addr
  dev)))))
• gt
• Node(l,devs,nbrs,rt)
• Process(l, orign, ardev, ssn, (rb - int),
• RedState(cx, Dummy))
• Packet(dest, dest, orign, ssn, (int - 1),
  NoRoute, val, vall)
• if connection(devs,nbrs,(dev gtgt dest)) and
• (rb gt int) and (int gt 0) .

28
Packet Delivery Rule

• crl Node(l,devs,nbrs,rt)
• Packet(dest, fdest, orign, ssn, rb, rf, val,
  vall)
• gt
• Node(l,devs,nbrs,rt)
• Process(l, orign, dest, ssn, rb, RedState(?,
  (val vall) ))
• if (dest fdest) and contains(devs,dest) .

29
Using the SpecificationAnalyzing Find

• Exploration of small scenarios gives better
  insight
• Execute -- how does it work
• Search -- for interfering Puts
• Model Check -- for multiple results

30
Sample Execution

• rew example-topology
• Process(loc("l0"), addr("i0"), addr("i0"), 1,
  100,
• RedState(?, find-prog-2(addr("e4")))) .
• result Configuration
• FreshKey(11)
• Data(loc("l0"), DataItem("", 10, Addr
  addr("i0"), 200))
• Data(loc("l1"), DataItem("", 10, Addr
  addr("a0"), 200))
• Data(loc("l2"), DataItem("", 10, Addr
  addr("b1"), 200))
• Data(loc("l3"), DataItem("", 10, Addr
  addr("c1"), 200))
• Data(loc("l4"), DataItem("", 10, Addr
  addr("e3"), 200))
• Data(loc("l5"), DataItem("", 10, Addr
  addr("d3"), 200))
• ...
• Process(loc("l0"), addr("i0"), addr("a0"), 1,
  4,
• RedState(?,Print (Cons (Addr addr("a1"),
• Cons (Addr addr("c3"),
• Cons (Addr
  addr("e4"),Nil))))))

31
Find Execution
find(e4)
d2
b
a
d
c
e
32
Sample Search

• search 1 i222e4 gt TwoPuts
• where
• TwoPuts is the pattern
• cnfConfiguration
• Process(lLoc, srcAddr, idev0Addr, snInt,
  rb0Int,
• RedState(cx0Cx,
• (Put (String "", Key k0Int,
• Addr prev0Addr, Int 200))))
• Process(lLoc, srcAddr, idev1Addr, snInt,
  rb1Int,
• RedState(cx1Cx,
• (Put (String "", Key k1Int,
• Addr prev1Addr, Int 200)))) .
• A solution is found with two processes executing
  on node l3, one coming from address c1 and the
  other coming from address d2.

33
Find Search Result
search init-e4 gt TwoPuts
b
a
d
a1
c
e
P(3,c1)
P(3,d2)
34
Find Model Checking Example
subsort Configuration lt State op PrintTwice -gt
Prop . eq (C Process(loc("l0"), addr("i0"),
ariv, 0, rb, RedState(?, Print v))
Process(loc("l0"), addr("i0"), ariv', 0, rb',
RedState(?, Print v')))
PrintTwice true . op init-a1 -gt
Configuration . a
3-node network with find packet red
modelCheck(init-a1, PrintTwice)
. result a counterexample showing a possible
computation in which two distinct paths from
source to destination were returned ( Printed) to
the source.
35
Model-checking for two paths
red modelCheck(init-c1, PrintTwice) .
c1
find(c1)
a
c
b
36
Properties

• Termination
• If a PLAN program is injected into the network,
  then all associated processes terminate (assuming
  fairness, i.e. all packets are eventually
  delivered).
• Non-Interference
• PLAN programs with no shared data keys execute
  independently (assuming data storage the only
  effect and ignoring timing and congestion).
• Computing resource bound
• For a PLAN program to visit each node of a
  network it is sufficient to start with rb gt 2 wd
• d (diameter) length of the longest path)
• w (width) maximum number of neighbors

37
Recapping

• Formal specification fills gaps and resolves
  ambiguities of the original mathematical
  specification
• issues of names and binding
• environments in packets
• exception handling mechanism
• side-effects in higher-order iterators
• modeling concurrency/distribution
• Specification serves as execution environment for
  PLAN and for analysis of PLAN programs via
  Maudes state-space exploration and model
  checking tools
• xPlan is a language for mobile computation based
  on ?-calculus services which includes an
  interesting concept of remote function invocation
• another potential application scripting/glue
  language for web services

38

• Application II
• CIAO A Calculus of Imperative Active Objects

Work in Progress !
39
CIAO A Calculus of Imperative Active Objects

• Objective An executable Felleisen-style
  semantics for a concurrent, object-oriented core
  language expressive enough to represent practical
  sublanguages of C, Java, C ?
• Why would this be of interest ?
• OO languages common in global computing
  applications
• understanding their semantics and relationships
• alternative to stack/continuation-based machines
• reference semantics for other possibly more
  optimized encodings
• rewriting logic as common framework for code and
  specification
• semantics for verification of programs
• static and/or runtime analysis of programs using
  Maude
• interoperation/integration between Maude of OO
  languages
• framework to experiment with new type systems,
  program transformations, and language extensions

40
Approach

• Inspired by Abadi and Cardellis imperative
  ?-calculus, but
• on top of imperative ?-calculus
• no aim for extreme minimality
• Like in popular languages such as C, Java, C,
  Eiffel, OCaml
• support values and references, access objects via
  references
• distinguish attributes from methods (no method
  update)
• support inheritance, exceptions, and threads
• Related approaches
• Concurrent Object Calculus Gordon Hankin,
  1998
• Many approaches specific to Java including
• Middleweight Java Bierman, Parkinson Pitts
  2003
• Classic Java Flatt, Krishnamurthi Felleisen
  1998
• Concurrent Java Boyapati Rinard 2001
• But not conducted in an executable formal
  framework

41
Base Language (Loops Added)

• op __ String Nat -gt Ex .
• op _ _ Ex ExList -gt Ex .
• op __ Ex Ex -gt Ex .
• op If_Then_Else_ Ex Ex Ex -gt Ex .
• op While_Do_ Ex Ex -gt Ex .
• op Let___ IdList ExList Ex -gt Ex .
• op LetRec___ IdList ExList Ex -gt Ex .
• op Lam__ IdList Ex -gt Ex .
• op Try_Catch__ Ex Id Ex -gt Ex .
• op Throw_ Ex -gt Ex .

42
Object and Execution Model

• A configuration is a multiset of the form
  Fresh(oid) containing
• A counter Fresh(oid) maintaining the next fresh
  object id
• Objects with data
• lt oid cid fields gt
• Objects with methods
• lt oid cid fields methods gt
• Objects with active code
• lt oid cid fields methods
  RedState(cx,ex) gt

43
Two Dimensions
lt c Cell class Cell, val Int , Cell
Lamthis , get Lamthis , set
Lamthis gt
lt Cell Class new Lamthis gt
Inheritance
lt cc CountingCell class CountingCell,
super c, counter Int , Cell Lamthis
, get Lamthis , set Lamthis gt
lt CountingCell Class super Cell new
Lamthis gt
Classification
44
Objects, Fields, Methods

• op Null -gt Const .
• op lt_gt Nat -gt Const .
• op __ Id Ex -gt AttrEx .
• op Objectlt_____gt Id Id AttrExList
  AttrExList Ex -gt Ex.
• op New_ Ex -gt Ex .
• op _._ Ex Id -gt Ex.
• op _.__ Ex Id Ex -gt Ex .
• op __at__._(_) Ex Ex Id ExList -gt Ex .
• rl Fresh(p)
• lt q cid aexl mexl
• RedState(cx, New Object lt self
  cid' avall' mexl' ex' gt ) gt
• gt
• Fresh(s p)
• lt q cid aexl mexl
• RedState(cx, lt p gt ) gt
• lt p cid' avall' self lt p gt mexl'
  RedState(?, self lt p gt ex' ) gt .

45
Field Access

• crl Fresh(m) obj objs gt Fresh(m) obj
  objs
• if lt q cid aexl mexl RedState(cx, lt p gt
  . id) gt obj /\
• ex' getField(obj objs, p, id) /\
• obj setRedState(obj, RedState(cx, ex')) .
• crl Fresh(m) obj objs gt Fresh(m) obj
  objs
• if lt q cid aexl mexl RedState(cx, lt p gt .
  id val') gt obj /\
• (obj, objs ) setField((obj,objs), p, id,
  val') /\
• obj setRedState(obj , RedState(cx, val'))
  .

46
Method Invocation

• crl Fresh(m) obj objs gt Fresh(m) obj
  objs
• if lt q cid aexl mexl RedState(cx, lt p gt _at_
  lt p' gt . id (vall)) gt obj /\
• Lam this,idl ex getMethod(obj objs, p',id)
  /\
• obj setRedState(obj, RedState(cx, this lt
  p gt idl vall ex)) .
• Syntactic Sugar
• op _._(_) Ex Id ExList -gt Ex.
• eq val . id (exl) val _at_ val . id (exl) .

47
Inheritance via Object Chaining

• Maintain a reserved field super referring to
  the ancestor object.
• op super AttrExList gt Nat .
• ceq super(aexl) p if lt p gt get(aexl,super) .
• op get AttrExList Id gt Ex .
• eq get(((id ex),aexl), id')
• if id id then ex else get(aexl,id') fi .
• op getField Configuration Nat Id gt Ex .
• eq getField(lt p cid aexl mexl rstate gt
  store, p, id)
• if (get(aexl,id) Ex) then get(aexl,id)
• else getField(store, super(aexl), id) fi .
• Operations getMethod and setField defined
  analogously.
• But No operation for method update !

48
Example Java

• Java-- -gt CIAO
• representation mapping
• Java well-typed, various well-formedness
  conditions
• The mapping is more complicated than the mapping
  PLAN -gt xPLAN, e.g overloading needs to be
  resolved, but it could be defined equationally
  inside Maude.

Java--
CIAO
49
Java-- Restrictions

• core language with elementary threads (no
  low-level features)
• no libraries that cannot be expressed in the core
  language
• no dynamic class loading, stack/bytecode
  inspection,
• overloading resolved using unique names
• all class and instance variables are explicitly
  initialized to default values
• superclass initializer invocations are explicit
• restrictions that might be lifted in the future
• values limited to data types of Bool, String, and
  arbitrary long Int
• restricted set of builtin operators
• restricted set of control structures
• no casting among values
• no arrays
• no access to hidden instance variables
• no synchronized modifiers/blocks
• no interfaces
• no finalizers
• no packages, everything is public

50
Representation Mapping

• Class Object Structure Constructors
• for objects and classes add super field for
  inheritance and initialize with super object
• for objects add class field to refer to class
  variables/methods and initialize with class
  object
• each class has a new() method that creates an
  object instance with default values
• new() uses self.super.new() to create object of
  super class with default values
• initialization method needs to be called
  explicitly directly after object creation using
  new()
• static initialization blocks need to be called
  explicitly directly after class creation
• Local Variables
• local non-reference variables/arguments of
  methods that are modified must be boxed
• accesss such variables requires explicit unboxing
  (Unbox) and/or special assignment ()
• Instance Variables
• access to nonlocal instance variable o.x
  translates to o.x
• access to local instance variable this.x (or
  simply x) translates to self.x
• access to super instance variable super.x
  translates to self.super.x
• Class Variables
• access to nonlocal class variable c.x (or simply
  x) translates to c.x
• access to local class variable this.x (or simply
  x) translates to self.class.x
• Instance Methods
• invocation of nonlocal class method c.m(...) (or
  simply m()) translates to c.m(...)

Not Implemented Yet !
51
Sample Program

• Let 'Cell
• New Object lt self 'Class
• new Lam this
• New Object lt self 'Cell
• 'val Int 0
• 'Cell Lam
  this,'init
• self . 'val 'init,
• 'get Lam 'this
• self . 'val,
• 'set Lam 'this,'newval
• self . 'val 'newval gt gt
• Let 'cell1 'Cell . new () 'cell1 . 'Cell (Int
  5)

class Cell int val 0 Cell()
Cell(int init) val init int
get() return val void set(int newval)
val newval Cell cell1 new
Cell(5) Cell cell2 new Cell(6) cell1.set(7)
cell2.set(cell1.get())
52
Syntactic Sugar Class Definitions

• op NewClass_lt___gt Id Id AttrExList
• 
  AttrExList -gt Ex .
• op NewClass_Extending_lt___gt Id Ex Id
  AttrExList AttrExList -gt Ex .
• eq New Class cid lt sid aexl mexl gt
• New Object lt self 'Class
• new Lamthis
• New Object lt sid cid aexl mexl gt
  gt .
• eq New Class cid Extending ex lt sid aexl mexl
  gt
• New Object lt self 'Class
• new Lamthis
• New Object lt sid cid super (ex .
  new ()), aexl mexl gt gt .
• Can be generalized to deal with class
  attributes/methods.

53
Sample Program with Sugar

• Let 'Cell
• New Class 'Cell lt self
• 'val Int 0
• 'Cell Lam this,'init
• self . 'val 'init,
• 'get Lam 'this
• self . 'val,
• 'set Lam 'this,'newval
• self . 'val 'newval gt
• Let 'cell1 'Cell . new () 'cell1 . 'Cell (Int
  5)
• Let 'cell2 'Cell . new () 'cell2 . 'Cell (Int
  6)
• 'cell1 . 'set (Int 7)

class Cell int val 0 Cell()
Cell(int init) val init int
get() return val void set(int newval)
val newval Cell cell1 new
Cell(5) Cell cell2 new Cell(6) cell1.set(7)
cell2.set(cell1.get())
54
Sample Program with Inheritance
class Cell int val 0 Cell(int init) val
init int get() return val void set(int
newval) val newval class
CountingCell extends Cell int counter
0 CountingCell(int init) super(init) void
set(int newval) counter counter 1
super.set(newval) Cell cell1 new
CountingCell(5) Cell cell2 new
CountingCell(6) cell1.set(7) cell2.set(cell1.ge
t())

• Let 'Cell
• New Object lt self 'Class
• new Lam this
• New Object lt self 'Cell
• 'val Int 0
• 'Cell Lam this,'init self
  . 'val 'init,
• 'get Lam this self .
  'val,
• 'set Lam this,'newval
  self . 'val 'newval gt gt
• Let 'CountingCell
• New Object lt self 'Class
• new Lam this
• New Object lt self 'CountingCell
  
• super 'Cell . new (),
• 'counter Int 0
  
• 'CountingCell Lam
  this,'init
• self . super . 'Cell ('init),
• 'set Lam this,'newval
• self . 'counter self . 'counter Int 1

55
Sample Program with Class Variable

• Let 'Cell
• New Object lt self 'Class
• 'counter Int 0
• new Lam this
• New Object lt self 'Cell
• class self,
• 'val Int 0
• 'Cell Lam this,'init
• self . 'val 'init,
• 'get Lam this
• self . 'val,
• 'set Lam this,'newval

Maintain a reserved field class referring to
the objects class object.
class Cell static int counter 0 int val
0 Cell() Cell(int init) val init int
get() return val void set(int newval)
counter counter 1 val newval
Cell cell1 new Cell(5) Cell cell2 new
Cell(6) cell1.set(7) cell2.set(cell1.get())
56
Sample Program with Threads

• Let 'Thread
• New Class 'Thread
• lt self
• 'state Null
• 'run Lam this Skip,
• 'start Lam this
• self . 'state New Object lt self
  this . 'run () gt gt
• Let 'ThreadExt
• New Class 'ThreadExt Extending 'Thread lt
  self
• 'x Int 0
• 'run Lam this
• self . 'x Int 1 gt
• Let 'thread1 'ThreadExt . new ()
• Let 'thread2 'ThreadExt . new ()
• 'thread1 . 'start ()
• 'thread2 . 'start ()

Careful This naive representation allows
restarting of threads !
class ThreadExt extends Thread int x 0
public void run() x 1 ThreadExt
thread1 new Thread() ThreadExt thread2 new
Thread() thread1.start() thread2.start()
57
Use of Executable Semantics

• Execution and analysis of concrete programs
• Experimentally evaluate language design decisions
• Beyond concrete programs Symbolic Execution
• Partially execute programs with
  metavariables,but not only functional parts like
  in partial evaluation
• Program with metavariables and possibly
  constraints can be seen as entire class of
  programs
• Semantics needs to be carefully designed to
  localize causality and effects, otherwise
  symbolic execution gets stuck too soon to be
  useful
• Rewriting logic encourages us to think locally
  but does not enforce it (compare this with Petri
  Nets !)

58
Symbolic Execution

• rew
• Fresh(1)
• lt 0 'ActiveObject
• Let 'p New Object
• lt 'self 'Object
• 'x Int N,
• 'y Int 0 gt
• While ! ('p . 'y ? Int 4) Do
• ( 'p . 'x 'p . 'x 'p . 'y
• 'p . 'y 'p . 'y Int 1 ) gt
• .

Fresh(2) lt 0 'ActiveObject none
none noresult gt lt 1 'Object 'x Int
(N 6), 'y Int 4 none nocode gt
59
Symbolic Optimization

• Immediate Application of Symbolic Execution
• Idea Enhance efficiency by
• composing rewrites to form larger steps
• generalization of rules to enable reuse
• abstraction of rules (from redundant structure)
• localization of rules (remove redundant context)

o2.m(a2)
o1.m(a1)
o3.m(a3)


60
Sample Program

• Let 'Cell
• New Object lt self 'Class
• 'counter Int 0
• new Lam this
• New Object lt self 'Cell
• class self,
• 'val Int 0
• 'Cell Lam this,'init
• self . 'val 'init,
• 'get Lam this
• self . 'val,
• 'set Lam this,'newval

class Cell static int counter 0 int val
0 Cell() Cell(int init) val init int
get() return val void set(int newval)
counter counter 1 val newval
Cell cell1 new Cell(5) Cell cell2 new
Cell(6) cell1.set(7) cell2.set(cell1.get())
61
Select Pivot Statement to Optimize

• Let 'Cell
• New Object lt self 'Class
• 'counter Int 0
• new Lam this
• New Object lt self 'Cell
• class self,
• 'val Int 0
• 'Cell Lam this,'init
• self . 'val 'init,
• 'get Lam this
• self . 'val,
• 'set Lam this,'newval

62
Compute Concrete Pivot State
rew

• FreshRef(4)
• lt 0 'ActiveObject
• none
• none
• RedState(?,
• lt 2 gt . 'set(Int 7) ) gt
• lt 1 'Class
• 'counter Int 0
• new Lam this
• New Object lt self 'Cell
• class lt 1 gt,
• 'val Int 0
• 'Cell Lam this,'init self . 'val
  'init,
• 'get Lam this self . 'val,
• 'set Lam this,'newval
• self . class . 'counter
• self . class . 'counter Int 1
• self . 'val 'newval

lt 2 'Cell class lt 1 gt, 'val Int 5
'Cell Lam this,'init lt 2 gt . 'val
'init, 'get Lam this lt 2 gt . 'val,
'set Lam this,'newval lt 2 gt . class .
'counter lt 2 gt . class . 'counter
Int 1 lt 2 gt . 'val 'newval nocode
gt lt 3 'Cell class lt 1 gt, 'val Int
6 'Cell Lam this,'init lt 3 gt . 'val
'init, 'get Lam this lt 3 gt . 'val,
'set Lam this,'newval lt 3 gt . class .
'counter lt 3 gt . class . 'counter
Int 1 lt 3 gt . 'val 'newval nocode
gt
63
Generalize Pivot State

• FreshRef(4)
• lt 0 'ActiveObject
• none
• none
• RedState(?,
• lt 2 gt . 'set(Int 7) ) gt
• lt 1 'Class
• 'counter Int 0
• new Lam this
• Empty gt
• nocode gt
• lt 2 'Cell
• class lt 1 gt,
• 'val Int 5
• 'Cell Lam this,'init
• lt 2 gt . 'val 'init,
• 'get Lam this lt 2 gt . 'val,
• 'set Lam this,'newval

C FreshRef(F) lt P0 'ActiveObject F0
M0 RedState(CX, lt P2 gt . 'set(Int N3))
gt lt P1 'Class 'counter Int N1 new
Lam this Empty gt RS1 gt lt P2
'Cell class lt P1 gt, 'val Int N2
'Cell Lam this,'init lt P2 gt . 'val
'init, 'get Lam this lt P2 gt .
'val, 'set Lam this,'newval lt P2 gt
. class . 'counter lt P2 gt . class .
'counter Int 1 lt P2 gt . 'val 'newval
RS2 gt
64
Compute Generalized Target State

• C
• FreshRef(F)
• lt P0 'ActiveObject
• F0
• M0
• RedState(CX,
• lt P2 gt . 'set(Int N3)) gt
• lt P1 'Class
• 'counter Int N1
• new Lam this
• Empty gt
• RS1 gt
• lt P2 'Cell
• class lt P1 gt,
• 'val Int N2
• 'Cell Lam this,'init
• lt P2 gt . 'val 'init,
• 'get Lam this

C FreshRef(F) lt P0 'ActiveObject F0
M0 RedState(CX, Int N3) gt lt P1
'Class 'counter Int (N1 1) new Lam
this .. Empty gt RS1 gt lt P2
'Cell class lt P1 gt, 'val Int N3
'Cell Lam this,'init lt P2 gt . 'val
'init, 'get Lam this lt P2 gt .
'val, 'set Lam this,'newval lt P2 gt
. class . 'counter lt P2 gt . class .
'counter Int 1 lt P2 gt . 'val 'newval
RS2 gt
rew
65
Rule Abstraction Localization

• lt P0 'ActiveObject
• F0
• M0
• RedState(CX,
• lt P2 gt . 'set(Int N3)) gt
• lt P1 'Class
• 'counter Int N1
• M1
• RS1 gt
• lt P2 'Cell
• class lt P1 gt,
• 'val Int N2
• M2
• RS2 gt

lt P0 'ActiveObject F0 M0
RedState(CX, Int N3) gt lt P1 'Class
'counter Int (N1 1) M1 RS1 gt lt P2
'Cell class lt P1 gt, 'val Int N3
M2 RS2 gt
gt
Very close to Maudes style of concurrent objects
!
66
Discussion

• How to ensure correctness ?
• Only add rules which are computed rewrites or
  admissible abstractions, but never remove rules
• Optimized rules rules should have priority to be
  effective
• Optimization does not preserve transient
  intermediate states, but these are states that no
  program should rely on
• -gt related issue multithreaded memory models
• Local execution is deterministic, but
• control flow can depend on conditionals
• program can be directly or indirectly recursive
• program can block if synchronization is added
• We need to generalize this technique
• perform case analysis on pivot state (-gt
  Narrowing)
• perform optimization piecewise
• until the next recursive call or
• until the next synchronization point
• Ideally Dynamic Optimization e.g. using
  reflection
• What is the relation to on-the-fly/just-in-time
  compilation ?

o1.m(a1)
67
Recapping

• Developing an executable Felleisen-style
  semantics for basic concepts of an OO language
  appears to be a fairly routine task.
• Concurrency can be elegantly expressed using
  multiset rewriting in rewriting logic.
• Many features are missing in our treatment e.g.
  initializer ordering, finalizers, interfaces,
  multiple inheritance, thread synchronization,
  modules/packages - some will be added soon.
• Some features are obviously at odds with a purely
  syntactic treatment e.g. byte code/stack
  inspection, dynamic class loading
• Reflection could be treated as long as it is
  sufficiently abstract, e.g. reflection API in
  Java.
• Treatment of memory models seems possible using
  relaxed causality constraints, but how to keep it
  simple/abstract ?
• An alternative would be to restrict the class of
  programs to a well-behaved sublanguage, and
  encapsulate specialties.

68
Related Work in our Group

• MSOS Modular Structured Operational Semantics
• Maude MSOS tool Braga Meseguer 2004
• JavaFAN Java Formal Analyser Farzan, Chen,
  Rosu Meseguer 2004
• Byte-code level direct encoding of JVM
• Source-code level stack/continuation-based
  machine
• Memory Models in Maude Duhrjati Hendrix 2002
• IOP JLambda Maude -gt Java Interoperability
• JLambda as a bridge Mason, Talcott 2004
• UPTS First-Order Rep. of Pure Type Systems
  Stehr 1999
• Addressing the problem ?-closure
• OCC Open Calculus of Constructions Stehr 2002
• Generalization of rewriting logic with dependent
  types
• MSR Cryptoprotocol Specification Language
• Execution and analysis tool based on mapping into
  OCC Cervesato Stehr 2004

69
Conclusion

• Theories and tools for language design and
  prototyping should not be missing in the arsenal
  of foundations for global computing
• Rewriting logic provides a uniform framework for
  functional, non-functional, and concurrent
  computing
• But needs to be complemented by concrete
  techniques, e.g. for representation of syntax and
  semantics
• Useful future work
• Automate generation of systematic parts of our
  representation.
• Generalize and automate symbolic optimization.
• Application I contains some interesting concepts
  that seem to be relevant not only for active
  networks but also for web services
• Application II bridges the gap between
  conventional OO programming and Maudes
  rule-based approach to OO