Hi Geoff:


>From ghulten@ccs.neu.edu Wed Aug  6 18:03:08 1997
>Subject: Derived edges, continued
>From: Geoff Hulten <ghulten@ccs.neu.edu>
>To: "Karl Lieberherr" <lieber@ccs.neu.edu>, <dem@ccs.neu.edu>
>
>Professor,
>
>So it looks like we've solved the problem of how we are going to
>pass arguments to derived edges (we could call them multi-sourced 
>edges like Greg did). We will solve the problem by requiring that
>any traversal that crosses one of them brings a visitor that contains
>the arguments (the additional sources).
>
>This seems very clear in the case where you want to use a single
>visitor, cross only one multi-sourced edge, and have all the 
>source objects in hand (as doug said, what happens if
>the 'join point' is a bit further down the tree?).  In addition to
>these problems, I also have  a feeling that using multi-sourced 
>edges has the potential to make adaptive programs more brittle, 

we want to avoid that

>instead of more flexible.  And I ALSO don't see how solving 
>multi-sourced functional edges is on the critical path towards
>a module system.  Wow, I must have gotten up on the wrong side

traversal through edges which triggers computation is needed
to build modules on top of each other.

>of the bed this morning...
>
>So here is what I could come up with for solutions:
>
>Each time a multi-sourced edge is traversed, all the visitors that
>the traversal is carrying along are shoved into an array and given
>to the edge calculation code (As Greg says, the the derived edge's 
>over method).  The over method can work out what it needs by talking
>with the visitors it gets...ugh.  This kind of works around the first

This talking will be a name matching.

>two problems (having multiple visitors, crossing more than one multi-
>sourced edge in a single traversal).

I was thinking of encapsulating the arguments into a seperate part:

Visitor = ...  <args> Arguments.

>
>Now the join point problem...Doug wrote:
>
>>This isn't so simple when the join nodes are further down in the class
>>graph, however.  Consider this extension to the class graph in question:
>>
>>    Graphs = ForwardGraph ReversedGraph.
>>    ForwardGraph = Graph.
>>    ReversedGraph = Graph.
>>    // rest is the same
>>
>>Now say the user wants to write this adaptive method:
>>
>>    Adjacency {
>>	void allNeighborsInForwardGraph(Graphs g)
>>	    through { -> *,neighbors,*
>>		      ForwardGraph }
>>	{ ... }
>>    }
>
>It seems that for this to work, we would need to have some ordering 
>constraints.  Wouldn't we have to say 'Go get that ForwardGraph before
>trying to traverse the -> *,neighbors,* edge'?  An alternative is to
>just break this into two operations, the first gets the ForwardGraph,
>and the second crosses the derived edge...hrm...  Doug?
>
>
>And the flexibility problem.  On page 17 of his tech report Greg wrote:
>
>'One of the disadvantages of having derived edges in the application 
>schema is that the schema can quickly become cluttered and fully
>connected.'
>
>He proposes that we need a module system to hide some of this clutter.
>I agree.  If we don't solve that problem, adaptive behavior may become
>burdened with shipping arguments around, or bypassing  multi-sourced edges
>that aren't relevant.  One thought is that we could make all multi-sourced
>edges have semantics like the hidden edges I proposed, that is, they
>are only traversed if they are explicitly mentioned in a traversal
>specification.  However, I think it would be better if we came up with
>the module system first, and then worried about multi-sourced edges.
>
>Buh.
>
>Any one have opinions on any of this?  Am I just being obtuse?
>
>-Geoff
>

I think we have to take it one step at a time:

Once we have the derived edges with the visitors as argument holders
for the multi-sourced edges, we can see how we can best deal
with the explosion of edges we could traverse. I am confident
that the right combination of startegy capabilities and module system
ideas will solve the problem. The derived edges are very useful
without a module system in place.

-- Karl