Mira and Doug had just about the same reaction to my proposal 
of guarded visitor entries: They felt that only one strategy
edge should be used as guard and not an entire strategy graph.

Regarding my example:

strategy graph:
A = B C.
B = D.
C = D.
D = E.
E = F.

guard from A via B to F  before F (@ @)

Doug responded that the strategy graph should be rewritten as

A = B.
B = F.
C = F.

and now we can use the simpler guard:

guard from B to F  before F (@ @)

So for now we only use strategy edges as guards and we can 
see how far we get with that.

The meaning of 
guard from B to F  before G (@ code @)
is that code is only executed if we enter G while going from B to F.

-- Karl
================
Asking for feedback regarding another use of strategies.

Mira and I have a discussion about strategies as guards.
The reason is that certain visitors have detailed needs to
be informed about traversal events such as whether we enter
a node from some other node.

A toy example:

// traversal = from A to C
Count_Visitor {
  (@ int c; @)
  init (@ c=0; @)
  guard from A via B to C before X (@ c++; @)
  guard from A via D to C before Y (@ c++; @)
  before X (@ ... @)
  return int (@ c; @)
}

Here we want to count the X-objects which are reached by strategy
from A via B to C and the Y-objects which are reached by strategy
from A via D to C.

We have useful applications in the context of graph algorithms.

The general theme here is to guard visitor entries by strategies
to define traversal events.

Would such a feature make sense in Demeter/Java? Have you seen the need
for guarded visitor entries during your AP work?

-- Karl