From dougo@ccs.neu.edu Sun Aug 10 19:43:02 1997 Received: from vega.neu.edu (vega.ccs.neu.edu [129.10.115.77]) by amber.ccs.neu.edu (8.8.6/8.7.3) with SMTP id TAA13969; Sun, 10 Aug 1997 19:42:54 -0400 (EDT) Received: by vega.neu.edu (SMI-8.6/SMI-SVR4) id TAA22802; Sun, 10 Aug 1997 19:42:42 -0400 Date: Sun, 10 Aug 1997 19:42:42 -0400 Message-Id: <199708102342.TAA22802@vega.neu.edu> From: Doug Orleans To: Geoff Hulten Cc: "Karl Lieberherr" , Subject: Re: Derived edges, continued In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid X-Face: (4D-osoq?}7M3\EgvbWKo And I ALSO don't see how solving multi-sourced functional edges is > on the critical path towards a module system. Me neither... how did we arrive at this topic, anyway? > It seems that for this to work, we would need to have some ordering > constraints. Wouldn't we have to say 'Go get that ForwardGraph before > trying to traverse the -> *,neighbors,* edge'? Greg's solution was to have a list of "prepared" edges, where an edge is prepared iff all its source objects are available (either as arguments to the method or results of traversing previous edges). Then you keep traversing prepared edges, which prepares other edges, etc, until you get to the target. So in this case, the "neighbors" edge wouldn't be prepared until the edges from Graphs through ForwardGraph to Graph have been traversed. The ordering of edges is then automatically deduced, with ties broken arbitrarily. > However, I think it would be better if we came up with the module > system first, and then worried about multi-sourced edges. I agree. It seems like modules and generalized edges are orthogonal features, and modules are more important. --Doug