@TECHREPORT{demf:bryan,
AUTHOR = "Bryan Chadwick and Karl Lieberherr",
TITLE = "{Functional Adaptive Programming with DemeterF}",
YEAR = "2008",
INSTITUTION = "Northeastern University, Boston",
MONTH = "March",
NUMBER =  "NU-CCIS-08-March19"
}

Notes by Karl:

Relational Techniques

James Noble et al. write in: http://portal.acm.org/citation.cfm?id=1119668

The relationships between objects in object-oriented programs are as important as the objects themselves. Unfortunately, most object-oriented programming languages provide little support for such relationships, leaving the task of implementing them entirely to the programmer. Relationships are typically hard-coded into the participating classes, resulting in tangled code that unnecessarily couples these classes together.

In DemeterF we reason in terms of compositions of relations (or paths in class graphs). In the type-unifying case, we rely on the fact that the correct object will appear in a certain position. How it gets there is unknown by the time of the program writing and it is only known when the class graph is given.

Two kinds of traversal control

In DemeterF we have two kinds of traversal control: through bypassing clauses in traversals and through the combine methods. Those two techniques complement each other. The traversal control through the combine methods is a positive backward control.

T combine(NodeInt o,int i, T l, T r){return fold(l,r);}

means that there must be a T-carrying path to the second and third argument, but not to the first. The program should not contain any dead combine methods.

T combine(Object o){return new T(default);}
T combine(NodeInt o,int i, T l, T r){return fold(l,r);}

is like bypassing any 1 or 3 or higher and any 2 that does not start with an int.

Fibonacci numbers and Dynamic Programming

DemeterF promotes a dynamic programming approach to solve problems. Foe example, to compute the Fibonacci numbers, use the following bare list structure:

Num : Successor | Zero.
Zero = .
Successor = "'"  Num.

Fib = extends IDb. // function class to compute Fibonacci number Previous2 = "x " int " y " int. The resulting code is the dynamic programming solution:

Previous2 combine(Successor nonempty, Previous2 p){
  Previous2 h = new Previous2(p.get_x() + p.get_y(), p.get_x());
  return h;
}
Previous2 combine(Zero i){
  return new Previous2(1,0 );
}

which is is much more efficient than the recursive program.

Modeling DemeterF programs with logic programs

RevPath(X.left, T tl) && RevPath(X.right, T tr) =>
  StartPath(X, T fold(tl,tr))
T combine(X x, 
  // 
  T tl,
  T tr)

RevPath(X.left, T tl) means: if there exists a path to X.left carrying object tl of type T.

StartPath(X,T t) means: there is a path starting at X carrying t of type T.

The class subgraph selected by the strategy provides the information to connect those paths.

Can we use Datalog to model DemeterF programs and reason about them? What kind of statements can we prove about the programs? Might lead to an algebraic approach to adaptive programming.

Tailor-made Data Management

Connection to http://www.dagstuhl.de/de/programm/kalender/semhp/?semnr=2008281 (Software Engineering for Tailor-made Data Management)

What is Different

With DemeterF the Law of Demeter becomes: listen only to your friends, instead of talk only to your friends.

The code you write is invoked implicitly: Implicit invocation: http://en.wikipedia.org/wiki/Implicit_invocation. The function objects register for a traversal.

Programming using a flow.

Two kinds of traversal control.

Reasoning in terms of paths; connection to logic programming?

Type checking of DemeterF programs

Which class graphs does the type-checker exclude? It protects against certain "illegal" generalizations of the program statically. If the type checker would not be used, we would detect the problem eventually dynamically. This is similar to constraints on class graphs which also exclude certain bad class graphs.

A new view of AP

Instead of viewing it as a class graph generic programming technology, let's view it as a non-generic programming technology that adds great fluidity to the programs so that generalizations can be easily accomplished.

Equality Visitor

There is one more visitor in DemeterJ that has not yet found an easy simulation in DemeterF: The EqualityVisitor. How can we incrementally modify an equality function in the same way as we currently can modify the default copy function.

DemeterF for Ruby

http://weblog.raganwald.com/2006/01/finding-signal-to-noise-ratio-in-never.html How many lines of code do you need in Java? Here's how you express the Java idiom of the Visitor pattern in Ruby:

concrete.each { |thingy| visitor.visit thingy }

If visitors are easy in Ruby, what about a Ruby version of DemeterF?

Better Titles:

Removing Structural Accidental Complexity from Programs

Eliminate accessors: This does not capture what is important: we move from a push model to a pull model. In other words: from "talk to your friends" to "listen to your friends". We still talk about fields, but do it by position only.

Work related to parameterized class dictionaries:

@article{1040310,
author = {Haruo Hosoya and Alain Frisch and Giuseppe Castagna},
title = {Parametric polymorphism for XML},
journal = {SIGPLAN Not.},
volume = {40},
number = {1},
year = {2005},
issn = {0362-1340},
pages = {50--62},
doi = {http://doi.acm.org/10.1145/1047659.1040310},
publisher = {ACM},
address = {New York, NY, USA},
}

Life without getters