�ݺ�ߣ

Structural Version Control
You know, it’s always safe to put “Towards” in the title
when you haven’t done much ;-)
Towards
1
Yin Wang

2
Q: What’s the best way to solve HARD problems?
A: Don’t solve them. Make them DISAPPEAR.
This often just requires a slight change of DESIGN.

Introducing “Structural Programming”
3
Disambiguate:
Structural Programming
not Structured Programming
The idea has been decades old
Lambda calculus is even older
“What goes around comes around”

Outline
Structural Editing (other people’s work)
Structural Comparison (my work)
Structural Version Control (vaporware)
4

Programs are data structures
 Usually called “parse tree” or “AST” (abstract syntax tree)
5

Data structures are usually
encoded as text
function factorial(n) {
if (n == 0) {
return 1;
}
return n * factorial(n - 1);
}
The encoding scheme is called syntax
6
keywords,
delimeters

Parsers
 A parser is a decoder from text to data structures
 Parsers are tricky to write and hard to debug
We need parsers because we encode
programs into text!
7

Why text?
 Write programs that do one thing and do it well
 Write programs to work together
 Write programs to handle text streams, because that is a
universal interface
A universal interface =/= THE universal interface
8

Text is an inconvenient universal
interface
 Data has different types: String, Int, records, functions, …
 Text is just one type: String
 Why should we encode all other types into strings?
9

Programming without syntax
(demo: Kirill Osenkov’s editor prototype)
10
See also:
• MPS (JetBrains)
• Intentional Software
• Software Factories (Microsoft)
• paredit-mode (Emacs)

Potentials of Structural Editing
 Easily extensible to ALL programming languages
 Semantics-aware context help (limit number of choices)
 Unable to write ill-formed / ill-typed programs
 Efficient transformations and refactorizations
 Pictures, math formulas together with programs
 Incremental compilation at fine granularity
 Version control at fine granularity
11

New problems
 How do we display code in emails?
 Need to standardize a data format for parse trees
 Easy. We have been making standards all the time: ASCII,
Unicode, JPEG …
 How do we do version control?
 No more text means no more “lines”
 … means most VC tools will stop working!
12

Outline
13

ydiff: Structural Diff
 Language-aware
 Refactor-aware
 Format-insensitive
 Comprehensible output
 Open-source
Demo
14
http://github.com/yinwang0/ydiff

Ingredients
 Structural comparison
algorithms
 Generalized parse tree
format
 Home-made parser
combinator library
 Experimental parsers for
JavaScript, C++, Scheme, …
15

Parsec.ss: Parser Combinator
Library in Scheme
 Modeled similar to Parsec.hs
 Macros make parsers look like BNF grammars (“DSL”)
 Left-recursion detection (direct / indirect)
16

Left-recursion Detection
trace
problem
token
17

Generalized Parse Tree Format
18

Parsers Built
 C++ (596 lines, incomplete, most of C++)
 JavaScript (464 lines, complete, may still contain bugs)
 (Scheme )
19

Key Algorithms
 Tree Editing Distance (TED)
 Move Detection
 Substructure Extraction
20

Tree Editing Distance
1
2 3
4
1
2 3
45
delete “4”?
insert “5”?
modify “4”
into “5”?
Minimize the
number of
changes that
make the two
trees equal
All three
cases are
equally
possible
Node -> Node –> [Change]
21
cost = 3
cost = 2
cost = 1

Types of Changes
 Deletion
 Insertion
 Modification
 Move
 Reparent (aka “refactoring”)
TED can handle
Observation: allowing modification generates incomprehensible results
22

Tree Editing Distance with
Recursion
diff-node diff-list
mutual recursion
Compare
two nodes
Compare
components of
the two nodes
23

diff-node :: Node -> Node –> [Change]
substructure
extraction from the
changes
base
cases
dispatch on
node types
memoization
only compare nodes
of the same type
compare
subnodes
24

diff-list :: [Node] -> [Node] –> [Change]
Otherwise, two
choices:
delete head1
or
insert head2
compare head
nodes
shortcut: same
definition or
unchanged
pick the
branch with
lower cost
25

Move Detection
 Some moved node can be detected by simple pairwise
comparison between DELETED and INSERTED change
sets.
normal diff (Git) ydiff
26

Substructure Extraction
frame: keep as a
new change for
further extractions
27

Outline
28

Merging in text-based version control 29
1 apples
2 bananas
3 cookies
4 rice
1 apples
2 bananas
3 beer
4 cookies
5 rice
1 apples
2 bananas
3 cookies
4 pasta
5 rice
Insert “pasta”
on line 4
Insert “beer”
on line 3
1 apples
2 bananas
3 beer
4 cookies
5 pasta
6 rice
Insert “pasta”
on line 5
Insert “beer”
on line 3
 Modifying a line of text
changes the line number of
consequent lines
 Patch that says “insert
pasta to line 4” must
relocate to line 5
  Patch Theory (Darcs)

Prediction 1: merging will no longer be
a problem in Structural Version Control
30

Modifying Different Nodes
31
1
2 3
4
Each node has a
GUID
Insert node #323F
containing “5” in node
#2EA4
Insert node #3248
containing “6” in node
#5B40
#2EA4 #5B40
#3224
#2048
1
2 3
45
#323F
#5B40
#3224
#2EA4
#2048
1
2 3
46
#3248
#5B40
#3224
#2EA4
#2048
1
2 3
465
#5B40
#3224
#2EA4
#2048
#3248#323F
Insert node
#323F containing
“5” in node #2EA4
Insert node #3248
containing “6” in
node #5B40

Modifying The Same Node
32
6
1
2 3
4 5
0.2 0.8
Insert node #2048
node #5B40, at
position 0.5
0.5
7
1
2 3
4 5
0.2 0.8
Insert node #2056
node #5B40, at
position 0.1
0.1
7
1
2 3
4 6 5
Insert node #2048 containing “6”
in node #5B40, at position 0.5
in node #5B40, at position 0.1
0.1 0.2 0.5 0.8
Because the real line can be infinitely divided, we
can always sort the numbers into relative positions!
100%
conflict-free
merging!!

What’s wrong?
33
0.2 x = 1
0.8 print y
0.2 x = 1
0.5 y = 2
0.8 print y
0.2 x = 1
0.5 blah
0.65 y = 3
0.8 print y
0.2 x = 1
0.5 y = 2
0.65 y = 3
0.8 print y
All line-based VC
tools have this
behavior. Try it!
Merge succeed,
but bugs introduced!

Modifying The Same Node
(a more sensible way)
34
6
1
2 3
4 5
Insert node #2048
node #5B40,
between #31FE and
#3208
7
1
2 3
4 5
Insert node #2056
node #5B40, before
#31FE
7
1
2 3
4 6 5
in node #5B40, between #31FE
and #3208
in node #5B40, before #31FE

Modifying The Same Node (again) 35
6
1
2 3
4 5
Insert node #2048
node #5B40,
between #31FE and
#3208
7
1
2 3
4 5
Insert node #2056
node #5B40,
between #31FE and
#3208
7
1
2 3
4 6 5
and #3208
and #3208
Conflict!

Some observations into text-base
VC tools
 Grounds are where programs sit on.
 Merging is hard because simultaneous edits change the
grounds in different ways, but text-based VC tools don’t have
a handle on them.
 This is why Darcs uses Patch Theory, which gives us limited
power for reasoning about the grounds.
 Git uses hash values to locate the grounds, but has larger
granularity. Also, hash values have dependency on the
contents.
 Once we have true handles on the grounds, the problem
disappears.
36

What’s next?
 Other scenarios
 HOW MUCH and WHAT context to include in the patches?
 A descriptive language for patches, and a constraint solver
for merging them?
 A database-like transaction system for parse tree structures?
 Let the structural editor construct the change sets?
 Generalize structural programming to natural languages?
37

�ݺ�ߣ

Towards Structural Version Control

Recommended

More Related Content

Similar to Towards Structural Version Control (20)

Recently uploaded (20)

Towards Structural Version Control