DemeterF: Functions and Traversals in Combination by 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 Transformer copy object after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

Parameterize Default Transformer PathSpec apply(J j) { return new Complement(j); } after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

Parameterize Default Transformer PathSpec combine(J j, Boolean fn, Boolean sn) { return fn && sn; } PathSpec combine(Object j, Boolean fn, Boolean sn) { return fn && sn; } after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

Simple application Program 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 New Var : Sym. Sym = Ident. Var : Sym | Addr. for later 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); }

The default Builder for PathSpec after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

well-formed movie show how the default builder is modified to combine Boolean objects.

The default Builder for PathSpec well-formed specialization 1 #t: true #f: false after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J #t :J 5 2 :S :S :S :S 3 #t 7 #t 8 #t 4 #t

The default Builder for PathSpec well-formed specialization 2 #t: true #f: false after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J #t :J #t 5 2 :S :S :S :S #t 7 #t 8 #t 3 4 #t

The default Builder for PathSpec well-formed specialization 3 #t: true #f: false after blue arrow copy is built (like after) #t 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 3 #t 7 #f 8 #t 4 #t

The default Builder for PathSpec well-formed specialization 4 #t: true #f: false after blue arrow copy is built (like after) #t 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. #f 6 :J :J 5 2 :S :S :S :S 3 #t 7 #f 8 #t 4 #t

The default Builder for PathSpec well-formed specialization 5 #t: true #f: false after blue arrow copy is built (like after) #t 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. #f 6 :J #t :J 5 2 :S :S :S :S #t 7 #f 8 #t 3 4 #t

The default Builder for PathSpec well-formed specialization 6 #t: true #f: false after blue arrow copy is built (like after) #t 10 #f :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 3 #t 7 #f 8 #t 4 #t

The default Builder for PathSpec well-formed specialization 7 #t: true #f: false after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 3 #t 7 #f 8 #t 4 #t

The default Builder for PathSpec well-formed specialization #t: true #f: false after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 #f 8 #t 3 #t 4 #t

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization means a copy after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization after blue arrow copy is built (like after) 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization insert NOT after blue arrow copy is built (like after) :N 10 :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

The default Builder for PathSpec NOT_JOIN_MERGE specialization insert NOT :M after blue arrow copy is built (like after) :N 10 :N :M 1 9 Count only upon first visit (red) and upon final visit (blue). For leaf nodes, count only in red. 6 :J :J 5 2 :S :S :S :S 7 8 3 4

Illustration of combine for capacity constraint violation 19 :C (w1+w2+w3+w4,2) :Cons (w1+w2+w3+w4,1) :E (w4,0) 1 20 2 18a 3 18 3a 13a :Cons (w1+w2+w3,1) after blue arrow combine is active (like after) 17a :C (w2+w3,1) 4 12a 17 :Cons (w1,0) 5 13 14 12 16a :Cons (w2+w3,0) 15a 6 :E (w1,0) :Empty (0,0) 11a 7a 15 16 11 :E (w3,0) :Cons (w2,0) 8 both containers (C) violate capacity constraints 7 10a 9a :E (w2,0) :Empty (0,0) 9 10

Illustration of combine for capacity constraint violation (w1+w2+w3+w4,2) :Cons (w1+w2+w3+w4,1) :E (w4,0) :Cons (w1+w2+w3,1) :C (w2+w3,1) :Cons (w1,0) :Cons (w2+w3,0) :E (w1,0) :Empty (0,0) :E (w3,0) :Cons (w2,0) both containers (C) violate capacity constraints :E (w2,0) :Empty (0,0)

Theory t[f,b](d) => d’, where d’=f(d), d is atomic On left side of => the term c(…) only indicates a compound object. Theory f = apply b = combine t[f,b](d) => d’, where d’=f(d), d is atomic t[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) => d id[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)

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 every apply/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 the modified 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 along an argument to the functions, all the way through recursive calls until it is needed. At a lambda the 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 where the 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 the argument when it's not really needed.

Traversal a function: