>From wand@ccs.neu.edu Thu Feb  5 11:41:09 1998
>Received: from delphi.ccs.neu.edu (wand@delphi.ccs.neu.edu [129.10.112.101])
>	by amber.ccs.neu.edu (8.8.6/8.8.6) with ESMTP id LAA01173;
>	Thu, 5 Feb 1998 11:41:05 -0500 (EST)
>Received: (from wand@localhost)
>	by delphi.ccs.neu.edu (8.8.6/8.8.6) id LAA22521;
>	Thu, 5 Feb 1998 11:41:04 -0500 (EST)
>Date: Thu, 5 Feb 1998 11:41:04 -0500 (EST)
>Message-Id: <199802051641.LAA22521@delphi.ccs.neu.edu>
>From: Mitchell Wand <wand@ccs.neu.edu>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>To: Johan Ovlinger <johan@ccs.neu.edu>
>Cc: lieber@ccs.neu.edu, dem@ccs.neu.edu
>Subject: Re: marry traversal automata/strategies
>In-Reply-To: <199802051525.KAA28804@mintaka.ccs.neu.edu>
>References: <199802051449.JAA14695@stockberg.ccs.neu.edu>
>	<199802051525.KAA28804@mintaka.ccs.neu.edu>
>X-Mailer: VM 6.31 under Emacs 19.34.1
>Status: R
>
>Karl wrote:
>
>KL> I was thinking about a marriage of traversal automata and strategies.
>KL> The nodes in a strategy graph can be viewed as states.
>KL> Consider the strategy with class map:
>
>KL> {-> q0:A q1:C
>KL>  -> q1:C q2:D}
>
>KL> The class graph is:
>KL> A = B.
>KL> B = [C] D.
>KL> C = B.
>KL> D = .
>
>KL> At class B we have the generated state transitions:
>
>KL> ((B q0) (TRAVERSE c q0)
>KL>  (B q1) (TRAVERSE c q1) (TRAVERSE d q1))
>
>There are some parens missing here. That's ok, but there are so many
>transitions missing I can't tell what you're trying to do.
>
>Does [C] mean a list of C's or an optional C?  If it's optional, then the
>traversals at B are both illegal. (We don't yet deal with optional parts).  If
>it's a list of C's, then (TRAVERSE c q1) is not appropriate-- maybe you want
>to say (FOR-EACH c q1), which is our mapping construct.  Or if you meant
>
>B = b:List(B) d:D.
>
>then you probably wanted to write something more like
>
>(B q0) => (for-each b q0) (traverse d q1)
>
>KL> Now the "marriage" would consist of allowing the strategy
>KL> specifier to take complete control at certain classes.
>
>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.
>
>JO> I was hoping you could explain
>JO> a bit further. To help my understanding, I've come up with two [very
>JO> quickly sketched out] counter proposals. Perhaps you could contrast
>JO> your suggestion to mine?
>
>JO> First of all, a notational Q:
>
>JO>    Consider the strategy with class map:
>
>JO>    {-> q0:A q1:C
>JO>     -> q1:C q2:D}
>
>JO> Am I reading this correctly as:
>JO>     from A to C (going from state q0 to q1 in the process)
>JO> and then C to D (going from state q1 to q2 in the process)
>
>That's how I read it.
>
>JO> Since I don't fully understand your email, I'll come out with a
>JO> counter proposal (two actually)- perhaps I'm repeating the essence of
>JO> your email?
>
>I'm sorry to say I didn't understand the proposal well-enough even to
>understand whether these counter-proposals are relevant.
>
>JO> 1)  Have the traversal automata be unaware of strategies (I still
>JO>     think of them as traversals...). 
>
>JO>     The user can write his own automata if he pleases, but we offer
>JO>     automatic translation from high level strategies. 
>
>This was roughly where I was heading.
>
>JO>     This solves no problem, but allows the compiler to only deal with
>JO>     automata descriptions as input.
>
>I don't understand this comment.
>
>JO>     Alternately, force the user to write automata, but do it over the
>JO>     abstract class graph that strategy-types are defined over (this would
>JO>     be the module signature eventually). I like this alot.
>
>It certainly sounds possible to write automata over "abstract class graphs" in
>which the edges are mostly virtual-- though I don't think that strategies are
>a good way to define virtual edges (except maybe to collection types-- see
>below).  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.  Johan touches on
>this issue again later.
>
>JO>     Or we could do both- offer expansion services, but only over the
>JO>     abstract graph, and if you want low level (ie highly representation
>JO>     dependent) traversals, you MUST write them explicitly. This sounds
>JO>     like a winner to me.
>
>I don't see any reason why a person shouldn't be able to write a strategy over
>a low-level class graph.  I think we've decided it's a bad idea ("strategies
>are brittle in dense class graphs"), but that's no reason to disallow it.
>
>JO> 2)  Bake strategies (I wrote traversal again, and had to erase it) into
>JO>     the automata. I think something like this is what you suggest
>JO>     (true?).
>
>JO>     We extend the language keywords (currently: visit traverse
>JO>     for-each) to include a 'strategy' action, so your [A,C][C,D]
>JO>     example would read (with apologies for incorrect syntax)
>    
>JO>     (q0       ;; initial strategy
>JO>      ((A q0) (strategy (to C) q1))  ;; at A in q0, traverse to C, 
>JO>                           ;; have state q1 when arrived at target
>JO>      ((C q1) (strategy (to D) q2)))
>     
>Yes, something like this sounds feasible, and may be what Karl was thinking
>of.  One difficulty is that strategies are inherently multi-target ("find ALL
>C's..") so that the semantics of
>
>    (strategy (to C) q1)
>
>would have to be "find all C's that are reachable from the current node, and
>traverse EACH OF THEM in state q1".  If this is what Karl was thinking of, it
>should not be hard to add.
>
>JO>     One question raised by this obviously quick proposal is:
>JO> 	 what and how are visitors called during strategy edges?
>JO>     I propose that they aren't called at all. The semantics can be
>JO>     well defined by viewing strategy actions as being expanded by the
>JO>     compiler to the other three traversal actions, but while God is in the
>JO>     details, I think they're fairly trivial, and would be a sidetrack
>JO>     at this point.
>
>I agree that visitors should not be called during a strategy edge.  The whole
>point of automata is to more closely regulate which visits are made when.
>(#include improper-list-strategy.flame.txt).
>
>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.
>
>--Mitch 
>
>
>
>
>
>
>