demeterf: functions and traversals in combination

DemeterF:Functions and Traversals in

Combinationby Brian Chadwick

Introduction

• Do EoPL functions using functional transformations

• Translate a class dictionary into a– traverser (that works with a visitor)– transformer (that works with function objects)

Default Transformercopy object

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9

10after blue arrowcopy is built(like after)

Count only uponfirst visit (red) andupon final visit (blue).For leaf nodes, countonly in red.

Parameterize Default Transformer

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



PathSpec apply(J j) { return new Complement(j); }

Parameterize Default Transformer

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



PathSpec combine(J j, Boolean fn, Boolean sn) { return fn && sn; }

PathSpec combine(Object j, Boolean fn, Boolean sn) { return fn && sn; }

Simple applicationProgram transformation

• Old– E : Num | Var | Op | Call …– Op : Plus | Equals.– Equals = “=“.

• New– E : … | Bool.– Bool : True | False.

class BoolTrans extends IDf { static E newtrue = Call.parse(“(= 1 1)”), static E newfalse= Call.parse(“(= 1 0) “); E apply(True t) {return newtrue; } E apply(False t) {return newfalse; }}

apply for transformation of result returned by builder

de Bruijn indices

• Old– Var : Sym.– Sym = Ident.

• New– Var : Sym | Addr.– Addr = Integer.

class AddrTrans extends IDf { Var apply(Var var, SymList senv) { return new Addr(senv.lookup(var));}}class SymExtender extends IDa { SymList update(Lambda l, SymList senv) { return senv.push(l.formals); }}

for later

The default Builder for PathSpec

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



well-formed movie

• show how the default builder is modified to combine Boolean objects.

The default Builder for PathSpecwell-formed specialization 1

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #t #t

#t


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #t #t

#t #t


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #f #t

#t


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #f #t

#t

#f


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #f #t

#f

#t

#t


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #f #t

#f#t


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #f #t

#f

The default Builder for PathSpecwell-formed specialization

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



#t: true#f: false

#t #t #f #t

The default Builder for PathSpecNOT_JOIN_MERGE specialization

:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9




:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



:S means a copy


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9




:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



insert NOT

:N


:S:S

:J

:S:S

:J

:M

1

2

3 4

56

7 8

9



insert NOT

:N :N

:M

:N

Illustration of combinefor capacity constraint violation

:C

:Cons

:E

:Cons

:E :Empty

:C

:Cons

:Cons:E

:E

(w1,0)

(w2,0)

(w3,0)

(w4,0)

(0,0)

(w1,0)

:Empty (0,0)

(w2,0)

(w2+w3,0)

(w2+w3,1)

(w1+w2+w3,1)

:Cons (w1+w2+w3+w4,1)(w1+w2+w3+w4,2)

both containers (C) violate capacity constraints

123

4

5

6

3a

7

7a

8

9

9a

10

10a

11

11a

12

12a13

13a

14

15

15a

16

16a

1717a

1818a

1919a

20

after blue arrowcombine isactive (like after)

Illustration of combinefor capacity constraint violation

:C

:Cons

:E

:Cons

:E :Empty

:C

:Cons

:Cons:E

:E

(w1,0)

(w2,0)

(w3,0)

(w4,0)

(0,0)

(w1,0)

:Empty (0,0)

(w2,0)

(w2+w3,0)

(w2+w3,1)

(w1+w2+w3,1)

:Cons (w1+w2+w3+w4,1)(w1+w2+w3+w4,2)

both containers (C) violate capacity constraints

Theory

t[f,b](d) => d’, where d’=f(d), d is atomict[f,b](c(d0, … ,dn)) => f(b(c(d0, … ,dn), d’0, … ,d’n)), where d’i =

t[f,b](di)Default functions:id[f](d) => did[b](c(d0, … ,dn), d’0, … ,d’n) => c(d0, … ,dn)b[c](c(d0, … ,dn), d’0, … ,d’n) => c(d’0, … ,d’n)

On left side of => the term c(…) only indicates a compound object.

f = applyb = combine

Theory

• f is a polymorphic function that takes a single argument and returns a result.

• b is a function object that is responsible for reconstruction of data types.

Traversal Component Approach

• implemented in DemeterF• Traversal with 3 components: Builder

(combine), Transformer (apply), Augmentor (update)

Augmentors / update methods

• so far: we covered combine and apply methods– combine: to combine information up the object– apply: to transform before the information is sent up.– up refers to the traversal: when a traversal has

finished visiting an object, it goes up.• add: update, to send information down the object• if it's not used/needed, it does not need to be

mentioned, since the traversal will do the passing around.

motivating example:Address computation

Var : Sym | Addr.Addr = Integer.class AddrTrans extends IDf { Var apply(Var var, SymList senv) { return new Addr(senv.lookup(var)); } }class SymExtender extends IDa { SymList update(Lambda la, Symlist senv){ return senv.push(la.formals); } }

Optional argument

• The argument passed *into* the traversal (by the programmer) is available everywhere (in everyapply/combine/update function) but it may be needed only in some objects.

• In the typechecker case is only needed when looking up a variable use, or modifying the type-environment with a binding.

Like a let for subtraversals

• An update argument can be viewed (almost) as a 'let' for sub-traversals: before traversing sub-terms we do a recalculation of the traversal argument. Update is called before traversing sub terms, and themodified value is only available for sub terms.

Structure-shy passing of argument• If you look at the Scheme code you would write to

traverse the same structure; you would pass alongan argument to the functions, all the way through recursive calls until it is needed. At a lambdathe recursive call on the body would look something like:

(type-Lambda l tenv) (cases Exp l (Lambda (arg body) (type-Exp body (tenv-extend tenv arg)))

(Call (op arglist) (let ((ret (type-Exp op tenv)) ...)

(... other cases...)))

Default: passing it along:no code needed with DemeterF

• Note that we don't change the traversal argument in most cases, only when binding an argument to a type. Usually we just keep passing it along throughout the traversal functions. The augmentor/update methods encapsulate (only) the changes of this argument, so we simply write:

• TEnv update(Lambda l, TEnv te) {return te.extend(l.formal);}• The traversal takes care of the default case

when we don't need to change the argument.

All arguments are optional

• All arguments are now optional... thus the most general method is: Object combine(){ return ...; }Since it is applicable in all cases (all arguments optional, including the 'traversal argument').(the traversal argument is the one updated by update methods. There is only one traversal argument)

AST illustration• Call

|--- Lambda | |--- Arg | | |--- Type | | | |--- int | | | | | |--- Sym | | |--- 'a' | | | |--- Call | |--- Plus | |--- Sym | | |--- 'a' | | | |--- Num | |--- 2 |--- Num |--- 4

Update is called at each label and the Object returned is then available to all terms 'connected'and to the right of that label.

Technical Details

• Methods you want to call determine from where you inherit: ID (all), IDa (update), IDb (combine), IDba (combine, update), IDf (apply), IDfa (apply, update), IDfb(apply, combine).

Motivation

• Showing a full scheme type-checking function, and highlighting the points wherethe type-environment is passed, used, and extended. The number of cases where it is just passed along motivates the want/need to put the modifications in one place, and being able to ignore theargument when it's not really needed.

Traversal

• a function:

demeterf: functions and traversals in combination

Documents

red andupon final visit

e applyfalse t

e applytrue t

builtlike aftercount

pathspec combineobject

pathspec combinej j

pathspec applyj j

leaf nodes