Structure-Shy Programming (SSP) Revisited

1
Structure-Shy Programming (SSP) Revisited

• Karl Lieberherr
• College of Computer and Information Science / PRL
• Demeter Research Group
• Northeastern University, Boston
• joint work with Ahmed Abdelmeged, Bryan Chadwick
  and Therapon Skotiniotis

2
Feedback

• Does target guarantee semantics without WYSIWYG
  make sense (Ralf)?
• problems with perobject. Outermost container.
• Can we guarantee that target guarantee holds
  without running the code (based on object
  invariants?)

3
What is Structure-Shy Programming?

• The program consists of modules (e.g., classes,
  aspects, functions).
• The modules depend on each others organization.
• A module M1 is structure-shy with respect to a
  module M2 if M1 refers to a safe organizational
  abstraction of M2 and not M2s detailed
  organization.
• Attempt generation of correct boilerplate code
  for M2 enabled by its safe abstraction.

4
Example

• M1 is structure-shy with respect to M2
• M2 DTD or XML schema or UML class diagram of
  Company
• M1 compute average salary
• M2.traverse(aCompany, from Company to Salary,
  SummingVisitor)

5
Example

• M1 is structure-shy with respect to M2
• M2 Java program
• M1 AspectJ aspect before all calls B.g() in
  the cflow of A.f() execute some code

6
Why do we need a revisit?

• XML activity XML schema and XPath, schema-aware
  processing
• Programming technology should become more
  structure-shy leads to more agile programs
• SYB Scrap your boilerplate work
• http//www.cs.vu.nl/boilerplate/
• by Ralf Laemmel and Simon Peyton-Jones and
  others.

7
Why do we need a revisit?

• Erik Meijer in LINQ 2.0 Democratizing the Cloud
  Our proposal boils down to separating data models
  from their query languages and leveraging the
  fundamental similarities in the operational
  semantics of each query language.
• What are the fundamental similarities? Strategy
  graphs should be common?

8
In C from Eriks paper

• from c in Customers
• where c.City Seattle
• select new c.Name, c.Age
• from c in Customers
• where schema.fetch(c, -gt City) Seattle
• select new c.Name, c.Age

9
Schema-aware XPath

• XPath 2.0 expression(element(,EqSystem)//elem
  ent(,Compound)//element(,Variable))

10
Used Variables in Compound
lhs
eqs

EqSystem
Equation
rhs
(element(,EqSystem)//element(,Compound)//elem
ent(,Variable) )
Expr
rrand
lrand
Compound
Simple
op
Op
Variable
Numerical

Ident
Integer
Add
Times
11
Used Variables in Compound
lhs
eqs

EqSystem
Equation
huge
rhs
(element(,EqSystem)//element(,Compound)//elem
ent(,Variable) )
Some Huge Diagram Without Compound
Expr
rrand
lrand
Compound
Simple
op
Op
Variable
Numerical

Ident
Integer
Add
Times
12
Traversal code

• class EqSystem
• R traverse()
• R1 r1 eqs.traverse()
• R2 r2 huge.traverse()

Based on meta information
(element(,EqSystem)//element(,Compound)//elem
ent(,Variable) )
13
Schema-aware XPath
XML Schema
How many traverse methods?
14
Schema-aware XPath

• XPath 2.0 expression(element(,A)//element(,
  B1)//element(,C1)//element(,D)element(,A)/
  /element(,B2)//element(,C2)//element(,D))
  

15
XML Schema
A-object
XPath Expression
How many traverse methods?
16
Danger of exponential compilation times
17
Dilemma

• Dilemma USE SCHEMA
• YES danger of huge compilation and run times
• NO danger of huge run times
• Solution to dilemma (mid 90s) Generate a
  non-deterministic
• automaton (the cross product of the class graph
  and strategy
• graph) and use it to guide the traversal. Leads
  to both
• efficient compilation and run-times!

18
XML Schema Adoption UsageStan KitsisMicrosoft
Corporation

• Schemas will play an important role in SOA and
  WS--based technologies. However unless the tools
  catch up with the ideas behind schemas many
  opportunities will be missed.
• 87 of developers use XML schema through VS
• presented in XML 2006 talk
• VS can generate schemas from document examples.

19
A Quick Tour of Adaptive programming

• schema.traverse(whatToTraverse, whereToGo,
  whatToDo)
• whatToTraverse an object aCompany
• whereToGo a graph sg with source s and target t.
• whatToDo a visitor
• semantics whereToGo defines an object graph
  slice of whatToTraverse. Traversal of object
  graph slice defines an event sequence that
  triggers the visitor methods.

20
Design space for WhereToGo

• A general graph (TOPLAS 2004)
• includes static XPath 2.0 expressions (linear
  graphs and series parallel graphs)
• positive and negative information about which
  nodes and edges to choose
• WYSIWYG

21
Design space for WhatToDo

• Various forms of visitors
• Focus today
• visitors with perobject variables perobject
  visitors
• functional visitors

22
Design Space WhereToGo-WhatToDo Combination

• Allowing premature terminations
• Disallowing premature terminations target
  guarantee semantics

23
The big picture for today

• Schema XML, UML, ER
• WhatToDo 1. per-object visitors / functional
  visitors
• WhereToGo 2. WYSIWYG
• WhereToGo / WhatToDo 3. target guarantee
  semantics
• Schema / WhereToGo 4. constraints

schema.traverse(whatToTraverse, whereToGo,
whatToDo)
24
Perobject Visitors

• A pattern that is easily implemented in
  programming languages (if you are willing to
  write the boilerplate).
• A small extension to
• our version of structure-shy programming (AP).
• DJ, our version of structure-shy programming in
  plain Java. Adding a _at_perobject annotation.
• A useful extension to the standard Visitor
  Pattern from GOF. An omission in the standard
  pattern.

25
Perobject Visitors

• They do two things introduce variables and
  disseminate them based on traversal-history.
• History-based visitors
• ordinary visitor variables make objects available
  down stream.
• perobject variable of class X refer to innermost
  enclosing object of class X. Done automatically
  without programmer intervention.

26
Presentation plan for perobject visitors

• The idea small motivating example the container
  capacity checking problem
• A simplified compilation problem proposed by
  Mitch Wand.
• A slightly larger example reducing a CNF.

27
Temporary extension during traversal
perobject myWeight int.
28
Temporary extension during traversal
At object level Container capacity 14
itemsItemPair firstContainer capacity 9
itemsItemPair firstElement weight
3 restItemPair firstElement
weight 7 restEmpty restItemPair
firstElement weight 3 restEmpty
perobject myWeight int.
29
Temporary extension during traversal
At object level Container myWeight 13 capacity
14 itemsItemPair firstContainer myWeight
10 capacity 9 itemsItemPair
firstElement weight 3 restItemPair
firstElement weight 7
restEmpty restItemPair firstElement
weight 3 restEmpty
perobject myWeight int.
30
Boilerplate for perobject

• public aspect CheckerVisitorStorage
• // The enclosing object of the per object
  variable myWeight
• public int CheckerVisitor.myWeight 0
• // The current object of the per Object
  variable myWeight
• public int container.Container.myWeight 0
• pointcut beforeContainer(CheckerVisitor v,
  container.Container c)
• target(v) args(c)
• execution(public void
  before(container.Container))
• within(CheckerVisitor)
• pointcut afterContainer(CheckerVisitor v,
• container.Container c)
• target(v) args(c)
• execution(public void
  after(container.Container))
• within(CheckerVisitor)
• // ...

31
More Boilerplate for perobjectafter-before /
before-after

• / after finishing the before method of the
  container just before leaving it to go down and
  continue the traversal, the current myWeight of
  the container is moved to the visitor so that it
  will be the enclosing container of the next
  container to be visited. The myWeight stored in
  the visitor is stored temporarily in place of the
  current myWeight of the container. /
• after(CheckerVisitor v, container.Container
  c)
• beforeContainer(v,c)
• int tmp c.myWeight
• c.myWeight v.myWeight
• v.myWeight tmp
• / before the after method is invoked on the
  container. the visitor's myWeight is restored and
  the proper value of the myWeight is captured
  from the visitor. /
• before(CheckerVisitor v, container.Container
  c)
• afterContainer(v,c)
• int tmp c.myWeight
• c.myWeight v.myWeight
• v.myWeight tmp

32
myWeight of innermost enclosing container
myWeight of parent container
Container capacity int items
List(Item). Item Element Container. Element
weight int.

• public class CheckerVisitor extends Visitor
• public int totalViolations 0 // no
  annotation needed
• _at_perobject class Container int myWeight 0
• public void before(Element e)
• myWeight e.weight
• public void after(Container c)
• myWeight c.myWeight
• boolean vio c.capacity lt c.myWeight
• if(vio) totalViolations

small code duplication because of recursion
traversal from Container to Element
33
Using the visitor

• Item o buildContainer()
• ClassGraph cg
• new ClassGraph(container,true,false)
• Visitor v new FilterU()
• cg.traverse(o, "from container.Container to
  container.Element,v)

34
combines concerns of weight summation, violation
predicate and conditional update.

• public class CheckerVisitor extends Visitor
• public int totalViolations 0
• _at_perobject class Container int myWeight 0
• public void before(Element e)
• myWeight e.weight
• public void after(Container c)
• myWeight c.myWeight
• boolean vio
• c.capacity lt c.myWeight
• if(vio) totalViolations

Lets separate them.
35
Separate the concerns(using Java)

• weight summation
• WeightVisitor
• violation predicate
• VioVisitor
• conditional update
• Updater
• CounterU
• FilterU

WeightVisitor
VioVisitor
Updater
FilterU
CounterU
36
weight summation
WeightVisitor

• public class CheckerVisitor extends Visitor
• public int totalViolations 0
• _at_perobject class Container int myWeight 0
• public void before(Element e)
• myWeight myWeight e.weight
• public void after(Container c)
• myWeight myWeight c.myWeight
• boolean vio c.capacity lt c.myWeight
• if(vio) totalViolations

traversal from Container to Element
37
violation predicate

• public class VioVisitor extends WeightVisitor
• _at_perobject class Container boolean vio
• public void after(Container c)
• super.after(c)
• vio c.capacity lt c.myWeight

traversal from Container to Element
38
conditional update abstract

• public class Updater extends VioVisitor
• public void after(Container c)
• super.after(c)
• if(vio) update(c)
• void update(Container c)

traversal from Container to Element
39
count

• public class CounterU extends Updater
• public int totalViolations 0
• void update(Container c)
• totalViolations

traversal from Container to Element
40
filter

• public class FilterU extends Updater
• public List violations new List()
• void update(Container c)
• violations
• new Cons(c,violations)

traversal from Container to Element
41
Using inheritance?

• Achieves purpose, but not optimal.
• public class Updater extends VioVisitor
• public void after(Container c)
• super.after(c)
• if(vio)update(c)
• void update(Container c)

hardwires Container. All that counts is aclass
C with per-object variable vio.
requires before/after C with perobject boolean vio
Updater
42
Interfaces match
public class VioVisitor extends WeightVisitor
_at_perobject class Container boolean vio public
void after(Container c)
super.after(c) vio c.capacity lt
c.myWeight
provides after C with perobject boolean vio
VioVisitor
43
Benefits of Abstractionwhat if we count and
filter?

• Visitor f new FilterU()
• Visitor c new CounterU()
• cg.traverse(o,
• "from container.Container
• to container.Element ,
• new Visitor(f,c))

WeightVisitor
VioVisitor
Updater
FilterU
CounterU
44
Benefits of Abstraction

• better modularity
• hint for efficiency the abstraction indicates
  which computations can be factored out.

WeightVisitor
VioVisitor
Updater
FilterU
CounterU
45
Do both count and filterequivalent to this
tangled code

• public class CheckerVisitor extends Visitor
• public int totalViolations 0
• public List violations new List()
• _at_perobject class Container int myWeight 0
• public void before(Element e)
• myWeight e.weight
• public void after(Container c)
• myWeight c.myWeight
• boolean vio c.capacity lt c.myWeight
• if(vio) totalViolations
• violations new Cons(c, violations)

46
Visibility of perobject variables

• A perobject variable of class C is accessible in
  all before/after methods of classes that are
  reachable from C without visiting C again. The
  variable refers to the innermost C-object visited
  during the traversal.
• The implementation uses a local visitor variable
  that points to the enclosing object.

47
Formula Reduction Visitor

• Formula clauses List(Clause)
• perobject sats int
• perobject unsats int
• perobject newClauses List(Clause).
• Clause literals List(Literal)
• perobject newLiterals List(Literal).
• Literal Pos Neg common Variable.
• Pos . Neg .
• Variable v int.

traversal from Formula to Literal
48
Formula Reduction Visitor
reduce with respect to l1

• void after (Literal l2) reduce(l1,l2)
• reduce(l1, l2)
• reduce(Pos(v), Pos(v)) true sats
• reduce(Neg(v), Neg(v)) true sats
• reduce(Neg(v), Pos(v)) false skip l2
• reduce(Pos(v), Neg(v)) false skip l2
• reduce(l1, l2) l2 if l1 and l2 do not refer to
  the same variable add l2 to newLiterals

49
Formula Reduction Visitor

• void after (Clause clause)
• if newLiterals is empty unsats else add clause
  to newClauses

50
The big picture for today

• Schema XML, UML, ER
• WhatToDo 1. per-object visitors / functional
  visitors
• WhereToGo 2. WYSIWYG
• WhereToGo / WhatToDo 3. target guarantee
  semantics
• Schema / WhereToGo 4. constraints

schema.traverse(whatToTraverse, whereToGo,
whatToDo)
51
Functional Visitor for Capacity Checking

• class FuncCheck extends FVisitor
• final int weight, violations
• FuncCheck(int w, int viol)
• weight w violations viol
• FuncCheck after(Element e, FuncCheck vis)
• return new FuncCheck(vis.weighte.weight,
  vis.violations)
• FuncCheck after(Container c, FuncCheck vis)
• return
• new FuncCheck(vis.weight,
• (vis.violations
• ((vis.weight-weight) gt
  c.capacity?10)))

52
Functional Visitor Communication
53
Functional Visitor for Capacity Checking

• class FuncCheck extends FVisitor
• final int weight, violations, myweight
• FuncCheck(int w, int viol, int myw)
• weight w violations viol myweight
  myw
• FuncCheck after(Element e, FuncCheck vis)
• return new FuncCheck(vis.weight,
  vis.violations,
• vis.myweight e.weight)
• FuncCheck after(Container c, FuncCheck vis)
• return
• new FuncCheck(vis.weight vis.myweight,
• (vis.violations
• (vis.myweight gt
  c.capacity?10)),
• myweight vis.myweight)

54
The big picture for today

• Schema XML, UML, ER
• WhatToDo 1. per-object visitors / functional
  visitors
• WhereToGo 2. WYSIWYG
• WhereToGo / WhatToDo 3. target guarantee
  semantics
• Schema / WhereToGo 4. constraints

schema.traverse(whatToTraverse, whereToGo,
whatToDo)
55
What you see is what you get

• Only positive directives in strategies
• No bypassing
• Simplification for presentation purposes
• Strategies are a list of edges that define a
  graph
• Each strategy edge is mapped to a pure path -
  no intermediate node is of a type that is
  mentioned in the strategy

56
Surprise paths

• A -gt B B -gt C
• surprise path A P C Q A B R A S C
• eliminate surprise paths
• A-gtB bypassing A,B,C
• B-gtC bypassing A,B,C

57
WYSIWYG strategies

• Avoid surprise paths
• Bypass all classes mentioned in strategy on all
  edges of the strategy graph
• Some users think that WYSIWYG strategies are
  easier to work with. I am among them.
• For WYSIWYG strategies, if class graph has a
  loop, strategy must have a loop.

58
Strategy Definition

• We can view strategies as

• Cs start node
• Cd end node
• C ? C strategy edge
• Applied to tree objects.

59
Strategy example

• We can view strategies as

A//B//C from A via B to C becomes
60
Paths and their correspondences

• Strategy paths paths in with source
  and target
• Object paths paths of objects in the heap
• Define

61
Path Expansion for strategy sg

• Path p is an expansion of q if we can obtain path
  q by removing some nodes from path p
• Path p is a pure expansion of path q if p is an
  expansion of q and all the nodes removed from p
  are not in sg

62
Valid Paths

• An object path op satisfies a strategy SG iff
  there exists a strategy path sp in SG such that
  types(op) is a pure expansion of sp.

63
What you see is what you getPure Paths
An object path o satisfies a strategy
iff there exists a
strategy path p such that
64
What you see is what you get

• Strategy exposes object types the visitor
  operates on
• New semantics are strict and allow only pure
  expansions of strategy edges
• Strategies need to be explicit about intermediate
  nodes, e.g.,

65
What you see is what you get

• Guarantee no surprise nodes in our paths.
• Visitor depends on types mentioned in strategy
• Semantics guarantee that an edge expands to a
  path that does not mention any type mentioned in
  the strategy
• Strategies become faithful models of paths in
  object graphs

66
The big picture for today

• Schema XML, UML, ER
• WhatToDo 1. per-object visitors / functional
  visitors
• WhereToGo 2. WYSIWYG
• WhereToGo / WhatToDo 3. target guarantee
  semantics
• Schema / WhereToGo 4. constraints

schema.traverse(whatToTraverse, whereToGo,
whatToDo)
67
Start walking only if you can make it to the end

• Split walking over objects into 2 steps
• Collect object paths that satisfy the strategy.

Heap
68
Start walking only if you can make it to the end

• Split walking over objects into 2 steps
• Collect object paths that satisfy the strategy.

Heap
Object Graph Slice
69
Start walking only if you can make it to the end

• Split walking over objects into 2 steps
• Get the list of paths and expand before and after
  method bodies

before(A) before(B) before(X)
before(Y) before(C)
after(C) after(Y)
after(X) before(C) after(C)
after(B) after(A)
aA
xX
Object Graph Slice
Method call trace
yY
cC
bB
cC
70
Implementation of target guarantee semantics

• Traverse with old semantics.
• Store unique path from root. When target is
  found, activate all the nodes on path they are
  in new object graph slice. Visitor will only be
  executed on activated nodes.
• When we hit a node that is activated, we can stop
  activation each node is activated only once.
• Requires activation bit per node.

71
What did we gain

• Strategy exposes
• Types the visitor can depend on
• Strict sequence of these types in paths
• Repeated types are explicit in the strategy
  (WYSIWYG)
• Runtime traversal
• Guided form our paths, collect complete object
  paths
• Execute visitor behavior on complete object paths

72
Guarantees to programmers

• When you begin traversing, you will get to an
  object of the target type
• Adaptive method gets its fair chance to set up
  its post-condition/invariant
• During traversal, no surprises due to early
  targets
• What you see is what you get!

Schema-awareness is important for efficiency
73
The big picture for today

• Schema XML, UML, ER
• WhatToDo 1. per-object visitors / functional
  visitors
• WhereToGo 2. WYSIWYG
• WhereToGo / WhatToDo 3. target guarantee
  semantics
• Schema / WhereToGo 4. constraints

schema.traverse(whatToTraverse, whereToGo,
whatToDo)
74
Making SSP safer

• Demeter interfaces

75
Writing the strategy forusedVars

• Capture variable references.
• Right-hand-side of equation can refer to
  variable(s).
• Strategies are non-empty.
• nonempty(gusedVars)

from Equation via -gt,rhs, to Variable
76
Used Variables.
EqSystem
Equation
lhs
rhs
Expr
rrand
lrand
Compound
Simple
op
Op
Variable
Numerical

Ident
Integer
Add
Times
77
Constraints

• Define conditions that need to hold on the
  underlying data structure
• Conditions apply to sets of paths.
• Constraint primitives.
• unique(s) , nonempty(s),
• subset(s1,s2), equal(s1,s2)
• Logical connectives.
• !

78
The big picture for todayConclusions

• Schema XML, UML, ER
• WhatToDo 1. per-object visitors / functional
  visitors
• WhereToGo 2. WYSIWYG
• WhereToGo / WhatToDo 3. target guarantee
  semantics
• Schema / WhereToGo 4. constraints

schema.traverse(whatToTraverse, whereToGo,
whatToDo)
79
Conclusions

• Structure-shy programming can be improved to
  facilitate reasoning about structure-shy
  programs
• Perobject visitors more intuitive programs
• WYSIWYG no early targets, faithful strategy
  paths
• Target guarantee complete path guaranteed
• constraints better capture of abstraction,
  easier schema evolution
• Schema-awareness improve efficiency using
  techniques from the 90s.

80
The End

• Thank you.

81
possible titles

• transportation visitors
• scoped visitors
• scoped introduction visitors
• per-object variable pattern
• perobject visitors
• visitors with per-object fields
• lambda visitor
• applicative visitors

82
Container capacity int items List(Item)
perobject myWeight int. Item Element
Container. Element weight int.
83
XML schema usage

• To generate boiler plate code
• To optimize XPath evaluation, e.g., XQuery
  evaluation
• and of course to verify documents

84
conditional update 1

• public class Counter extends VioVisitor
• public int totalViolations 0
• public void after(Container c)
• super.after(c)
• if(vio) totalViolations

traversal from Container to Element
85
conditional update 2

• public class Filter extends VioVisitor
• public int violations new List()
• public void after(Container c)
• super.after(c)
• if(vio) violations
• new Cons(c, violations)
  

traversal from Container to Element
86
Implementation / Visibility

• During the traversal of Container c contained
  inside a Container c0 we have inside the visitor
  methods two myWeight available this.myWeight
  (from enclosing container c0) and c.myWeight.
• From cContainer bypassing Container to Element
  determines visibility of c.myWeight.

87
Visibility

• Strategy sg (a general graph) with source s and
  target t.
• perobject variable v at s. Is visible where ss
  with bypassing s on every edge of ss visits.
• Example ss from s via b to t. Visibility is
  determined by from s bypassing s via b bypassing
  s to t.

88
Implementation

• We generate AspectJ aspects to update the
  perobject variables in the visitor as the
  traversal enters and leaves the objects where the
  perobject variable is attached.

89
Type of a Formula

• A list of pairs, where the first element, r, of
  each pair is a relation and the second, f, the
  number of uses of that relation in the formula.
• A relation is given by a pair (p,n) where p is
  the number of positive literals and n the number
  of negative literals.

90
Type Construction Visitor

• Formula clauses List(Clause)
• perobject newTypes List(Typ).
• Typ r Rel f int.
• Rel p int n int.
• Clause literals List(Literal)
• perobject cr Rel.
• Literal Pos Neg common Variable.
• Pos . Neg .
• Variable v int.

traversal from Formula to Literal
91
Type Construction Visitor

• void before (Formula f) newTypes new List()
  
• void before (Clause c) cr.p0 cr.n0
• void after (Pos l1) cr.p
• void after (Neg l1) cr.n
• void after (Clause c) newTypes Cons( new
  Typ(new Rel(cr.p, cr.n), 1), newTypes)
• void after (Formula f) consolidate newTypes and
  return them

92
Combined Formula/Type Reduction Abstract visitor
SatUnsat

• SatUnsat FormulaReduction TypeReduction.
• Formula clauses List(Clause)
• perobject sats int.
• Clause literals List(Literal) .
• Literal Pos Neg common Variable.
• Pos . Neg .
• Variable v int.

93
SatUnsat

• after Literal (l1 assignment, l2 clause)
  reduce(l1,l2)
• reduce(l1, l2)
• reduce(Pos(v), Pos(v)) true sats
• reduce(Neg(v), Neg(v)) true sats

94
Formula Reduction Visitor

• SatUnsat FormulaReduction TypeReduction.
• Formula clauses List(Clause)
• perobject newClauses List(Clause).
• Clause literals List(Literal)
• perobject newLiterals List(Literal).
• Literal Pos Neg common Variable.
• Pos . Neg .
• Variable v int.

95
Type Reduction Visitor

• Formula clauses List(Clause)
• perobject newTypes List(Typ).
• Typ r Rel f Fraction.
• Rel p int n int.
• Fraction v float.
• Clause literals List(Literal)
• perobject old_r Rel
• perobject new_r Rel.
• Literal Pos Neg common Variable.
• Pos . Neg .
• Variable v int.

traversal from Formula to Literal
96
Type Reduction Visitor

• after Literal (l1 assignment, l2 clause)
  reduce(l1,l2)
• reduce(l1, l2)
• reduce(Pos(v), Pos(v)) true sats
• reduce(Neg(v), Neg(v)) true sats
• reduce(Neg(v), Pos(v)) false skip l2
  old_r.p--
• reduce(Pos(v), Neg(v)) false skip l2
  old_r.n--
• reduce(l1, l2) l2 if l1 and l2 do not refer to
  the same variable add l2 to newLiterals

97
Type Reduction Visitor

• after Clause
• if newLiterals is empty unsats else add clause
  to newClauses

98
More efficient data structure

• Use linked list to point to clauses containing a
  particular variable.

99

• Formula clauses List(Clause) variables
  List(PNVar).
• perobject sats int
• perobject unsats int.
• PNVar Var pos LList(Clause) neg
  LList(Clause).
• Clause literals List(Literal)
• perobject newLiterals List(Literal).
• Literal Pos Neg common Var.
• Pos . Neg .
• Var v int.

traversal from Formula via PNVar to Literal
after PNVar v 1 sats length(pos) v 1 delete
v from neg v 0 sats length(neg) v 0 delete v
from pos after Clause if host empty unsats
object level assumptions from Formula via
clauses to cClause from Formula via pnPNVar
via pos to Clause if pn.var appears in c
positively. from Formula via clauses to cClause
from Formula via pnPNVar via neg to Clause if
pn.var appears in c negatively.
100
linked list

• LList(S) next DLList(S).
• Clause containedIn LList(Clause)

101
Related Work

• Environmental Acquisition (EA)
• original work by Lorenz and Gil
• formalization by Cobbe and Felleisen
• environmental acquisition of objects along
  containment links

102
EA (Cobbe/Felleisen)

• class A
• X x
• contains Y y
• acquires Z z
• Let a be an instance of A. Fields in the first
  two groups (here, x and y) are parts of a, and
  fields in the last group (z) are not directly in
  a but are rather acquired from as context.
  Further, only objects in fields in the second
  group (here, y) are considered to be contained in
  a, and therefore only they may acquire fields
  from a.

103
EA (in our case)

• class A
• X x
• contains Y y // defined by a strategy
• acquires Z z // defined by a strategy

104
XML Schema Adoption UsageStan KitsisMicrosoft
Corporation

• Schemas will play an important role in SOA and
  WS--based technologies. However unless the tools
  catch up with the ideas behind schemas many
  opportunities will be missed.
• 87 use XML schema through VS
• presented in XML 2006 talk

105
XML schema usage

• To generate boiler plate code
• To optimize XPath evaluation, e.g., XQuery
  expressions
• and of course to verify documents