Hi Doug:

>From dougo@ccs.neu.edu Sat Feb  7 03:41:25 1998
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: Mitchell Wand <wand@ccs.neu.edu>
>Cc: Johan Ovlinger <johan@ccs.neu.edu>, lieber@ccs.neu.edu, dem@ccs.neu.edu
>Subject: Re: marry traversal automata/strategies
>
>Sounds like Karl is busy with other things at the moment, so I'll see
>if I can chime in here.
>

Thank you! I appreciate this.
Yes, I was reading the Toronto work ...

>
>Mitchell Wand writes:
> > Does [C] mean a list of C's or an optional C?
>
>Optional.
>
> > KL> For example, we can refine the above strategy with
> > 
> > KL> ((A q0) (TRAVERSE b q0) (TRAVERSE b q3)
> > KL>  (B extend with 
> > KL>     (B q3) () // nothing
> > KL> )
> > 
> > KL> This means that at A we traverse the b edge twice and at
> > KL> B we go further only if in states q0 or q1.
> > 
> > And Johan replied:
> > 
> > JO> I'm afraid I don't understand exactly. 
> > 
> > Nor did I.  Maybe this is a discussion we should have at the group meeting
> > next Tuesday afternoon.
>

The strategy you refer to is:

{-> q0:A q1:C
 -> q1:C q2:D}

>Here's how I interpret it.  There's a strategy that goes from q0 to q1
>then to q2, and it's mapped onto the class dictionary so that q0 means
>class A, q1 means class C, and q2 means class D.  More precisely, the
>traversal is to start in state q0 at an object of class A, go through
>the object diagram until it gets to objects of class C, where it
>changes to state q1, then heads for objects of class D, where it
>changes to state q2.  

Exactly.

>In addition to this strategy, there are two
>extra annotations: one added explicit transition, from A in state q0
>through b to B, transferring to state q3; and one that says if we're
>at B in state q3 don't go anywhere.  One thing I'm confused about is
>why we'd need to say this last thing, since the original strategy
>didn't say anything about state q3 so nothing was going to happen
>anyway-- maybe adding the second B transition implies another
>iteration of the strategy to C?
>

I am no longer so sure about those annotations. I think now that a 
traversal automaton should have transitions of the form:

ClassValuedVar1 State1
  traverse relationValuedVar State2
  traverse to ClassValuedVar2 State3 constraint C1 //where C1 is a constrint like
						     in a constraint map

The second traverse is like an edge in a strategy graph.
When a class graph is given, this information is expanded into a detailed
traversal automaton as Mitch proposed them originally.

The above is in line with Johan's and Mitch's words:
It certainly sounds possible to write traversal automata over "abstract class graphs" ...

>
> > though I don't think that strategies are a good way to define
> > virtual edges 
>
>Why not?
>
> > This has the advantage that the edge wrappers, which were the most
> > problematic part of the semantics, would go away, and the rhetoric about
> > strategies would match the reality much more closely.  I'm thinking here of
> > the improper-list strategy and its attendant difficulties.
>
>I understand your complaint about the improper-list strategy (and I
>still think it's a non-issue), but what does this have to do with edge
>wrappers?  And why are they any more problematic than class wrappers?
>

I agree with Doug. We do graph-based programming and it is very natural
to attach code both to nodes and edges.

> > I agree that visitors should not be called during a strategy edge.
>
>I'm not sure why this is a big deal, but I sort of like the idea of
>forcing you to make explicit stops in the strategy when you want to do
>something somewhere.  This avoids the problem of "surprise" visits at
>classes that the strategy happened to come across that you didn't
>expect to see (i.e. Crista's complaint).  On the other hand, this
>forces you to impose an ordering on the midpoints of a traversal,
>which may be more structure-committing than you want.  For example,
>say you wanted to go from A to D, while doing something at B and C
>along the way.  You'd have to specify this as either A->B->C->D or
>A->C->B->D, but you may not care whether B comes before or after C, or
>even if they are not along the same path, like in this diamond class
>graph:
>
>    A = B C.  B = D.  C = D.
>
> > KL> Regarding visitor actions, I like a specification of the form:
> > 
> > KL> before
> > KL>   B         during {set of states} v1
> > KL>   -> B,c,C  during {set of states} v2
> > 
> > KL> same for after. Maybe we want a substrategy in addition to
> > KL> a set of states.
> > 
> > KL> It is important that we view the extended strategies to be defined
> > KL> in terms of class-valued variables.
> > 
> > I don't understand this at all.
>
>I think what he means is that, given a strategy, you auxiliarily
>specify that on the way down, as soon as we get to B, in the given set
>of states, do visit "v1", and before going down the c edge, do visit

Yes!

>"v2".  This would then get expanded into (binding "set of states" to
>"q0"):
>
>    ((B q0)
>	(visit "v1")
>	(traverse x q0)  ;; x is some other edge from B that
>			 ;; eventually leads to C
>	;; ...maybe other edges...
>	(if (not (null? c))  ;; this is how we deal with optional edges
>	    (begin
>	      (visit "v2")
>	      (traverse c q0)))
>	;; rest of edges
>    )
>
>This is all looking a lot like my AP/STklos implementation... should I
>exhume it?
>
>--Doug
>
Yes, Doug, please exhume it and we will put it on the Web as an unsupported
AP/STklos implementation. One tar file please.

-- Karl