>From johan@ccs.neu.edu Thu Feb  5 10:25:15 1998
>Received: from mintaka.ccs.neu.edu (mintaka.ccs.neu.edu [129.10.114.126])
>	by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id KAA27291;
>	Thu, 5 Feb 1998 10:25:12 -0500 (EST)
>Received: (from johan@localhost)
>	by mintaka.ccs.neu.edu (8.8.6/8.8.6) id KAA28804;
>	Thu, 5 Feb 1998 10:25:12 -0500 (EST)
>Date: Thu, 5 Feb 1998 10:25:12 -0500 (EST)
>Message-Id: <199802051525.KAA28804@mintaka.ccs.neu.edu>
>From: Johan Ovlinger <johan@ccs.neu.edu>
>To: lieber@ccs.neu.edu
>CC: dem@ccs.neu.edu
>In-reply-to: <199802051449.JAA14695@stockberg.ccs.neu.edu> (message from Karl
>	Lieberherr on Thu, 5 Feb 1998 09:49:07 -0500 (EST))
>Subject: Re: marry traversal automata/strategies
>Status: R
>
>Karl,
>
>I'm afraid I don't understand exactly. I was hoping you could explain
>a bit further. To help my understanding, I've come up with two [very
>quickly sketched out] counter proposals. Perhaps you could contrast
>your suggestion to mine?
>
>First of all, a notational Q:
>
>   Consider the strategy with class map:
>
>   {-> q0:A q1:C
>    -> q1:C q2:D}
>
>Am I reading this correctly as:
>    from A to C (going from state q0 to q1 in the process)
>and then C to D (going from state q1 to q2 in the process)
>
>Since I don't fully understand your email, I'll come out with a
>counter proposal (two actually)- perhaps I'm repeating the essence of
>your email?
>
>1)  Have the traversal automata be unaware of strategies (I still
>    think of them as traversals...). 
>
>    The user can write his own automata if he pleases, but we offer
>    automatic translation from high level strategies. This solves no
>    problem, but allows the compiler to only deal with automata
>    descriptions as input.
>    
>    Alternately, force the user to write automata, but do it over the
>    abstract class graph that strategy-types are defined over (this would
>    be the module signature eventually). I like this alot. Or we could
>    do both- offer expansion services, but only over the abstract
>    graph, and if you want low level (ie highly representation dependent)
>    traversals, you MUST write them explicitly. This sounds like a winner
>    to me.
>
>2) Bake stragegies (I wrote traversal again, and had to erase it) into
>    the automata. I think something like this is what you suggest
>    (true?).
>
>    We extend the language keywords (currently: visit traverse
>    for-each) to include a 'strategy' action, so your [A,C][C,D]
>    example would read (with apologies for incorrect syntax)
>    
>    (q0       ;; initial strategy
>     ((A q0) (strategy (to C) q1))  ;; at A in q0, traverse to C, 
>                          ;; have state q1 when arrived at target
>     ((C q1) (strategy (to D) q2)))
>     
>    
>    One question raised by this obviously quick proposal is:
>	 what and how are visitors called during strategy edges?
>    I propose that they aren't called at all. The semantics can be
>    well defined by viewing strategy actions as being expanded by the
>    compiler to the other three traversal actions, but while God is in the
>    details, I think they're fairly trivial, and would be a sidetrack
>    at this point.
>
>Karl,
>
>any of these seem plausible to you?
>
>Johan
>
>
>
>
>
>