Hi Mira:

>From mira@ccs.neu.edu Thu Dec  4 14:53:07 1997
>Cc: dem@ccs.neu.edu
>
>Hi Karl:
>
>
>> Hi Mira:
>>
>> I found two gems in your graph algorithms:
>>
>> 1.
>> Attaching code to strategy edges and
>>
>> 2.
>> Extending strategies with "reverse edges" to define derived edges.
>>
>> I consider those to be very elegant and important improvements.
>>
>> Re. 1:
>> Attaching code to strategy edges seems not be expressible
>> elegantly with other means. In you example, you attach code to the
>> strategy edge: source.Graph->target.Adjacency
>> and it means that each time we go back to Graph and we find again
>> an Adjacency object, we need to update the component count.
>> The implementation of this will need some code in both
>> Graph and Adjacency. How is code attachment to strategy edges
>> implemented in general?
> 
>When I wrotte the example, I was searching for a kind of
>finish method for the target node of a strategy. I used the 
>edge attachement since I was not sure whether it is possible to specify
>a finish method at another, non source node. What needs to be expressed
>is that we want to increase the number of components after finishing the
>traversal that goes thruogh the loop, i.e. from Adjucency through Vartex back
>to Adjucency, and before returning to the graph. This is the intended semantics 
>of attaching code to the edge s.source->target (I guess this is 
>what you mean by source.Graph->target.Adjacency). 
>

yes. By source.Graph->target.Adjacency I mean:
source and target are the names of the strategy graph nodes and
Graph and Adjacency are the names of the classes to which the strategy
graph nodes are mapped by the name map.

>
>But, looking at it the second time, I think that this semantics is
>better expressed by a finish method in Adjucency. In fact, we want
>to do something after returning from the edge source.Graph->target.Adjacency
>-- and for this purpose the above notation is misleading. It can be
>interpreted as doing component-number when entering 
>Adjucency which is wrong.  
>
>So suppose we have one of the following alternatives:
>	a) a finish method in Adjucency
>
>		ConnectivityVisitor {
>			...
>			s.target {
>				finish (@ component-number += 1; @)
>			  }
>			...
>		}

The above notation looks good at first sight: 
it says that when the traversal starting from
s.source (Graph) to s.target (Adjacency, after the loop) has finished, then
component-number += 1;

But what if s.target is replaced by some class (e.g. Adj) what is the meaning
of finish? We don't known which traversal needs to be finished.

>
>	b) a way to say after returning from Adjucency to Graph, e.g.
>  	   something like:
>		
>		ConnectivityVisitor {
>                        ...             
>
>			s.source->target {
>				after(@ component-number += 1; @)    
>                          }
>			
>			...
>		}

The above notation looks good in modified form. In general it could be:

	      after do s (@ component-number += 1; @) 
	      before do s before (@ component-number += 1; @) 

where s is a substrategy of the strategy of the visitor we are in.

For example: the overall strategy is: {A->B , B->C}

	     after {B->C} (@ c += 1; @)

says that each time the "from B to C" loop is completed, we add 1 to c.

-- Karl

>
>then, the implementation could be as follows:
>
>	// this is a simplified version of the generated code
>
>	Graph {
>	   ...
>	   connected-components (){
>	      for all adj in adjucency
>		{ 
>		  adj.connected-components(this);
>		  //now we are returning from the target
>		  component-number += 1;
>		}
>	      System.out.println (....);
>
>	  }
>
>	
>	Adjucency {
>	    ...
>	    connected-components (g)
>		if !mark 
>		  { 
>		    mark = true;
>		    for all v in neighbors 
>			{
>			 v.connected-components (g)
>			}
>	}
>
>	Vertex {
>            ...  
>            connected-components (g)
>		{
>		  for all adj in g.adjucency {
>			if (adj.source == this) then 
>				adj.connected-components (g)}
>		 }
>
>	  
> 
>			  
>	
>----------
>
>
>To my view, this is the same as the edge attachments that exist in DEM/Java, except that
>now we are talking in terms of strategy edges instead of concrete class dictionary
>edges.
>
>	
>-- Mira
>
>