Subject: Re: tranformations and node visiting
From: Keunwoo Lee (klee@cs.washington.edu)
Date: Sat Mar 03 2001 - 12:31:47 PST
On Fri, 2 Mar 2001, Jonathan Aldrich wrote:
> I think this is a classic example of why we need first-class multimethods.
> Imagine a method caching_visit, that takes a visit method and a thing to
> do during the visit. It first builds a cached vector in the correct visit
> order by invoking the visit method on an internal closure, then iterates
> over the vector, calling the user's closure.
>
> We could do this in Cecil with closures, but the interfaces and usage
> scenario would be really ugly. Can't wait for Diesel!
Maybe I'm misunderstanding you, but I don't see why this would be
especially ugly. All you have to do is wrap your visit method in a
closure:
object foo;
method my_visit_order(@foo):collection[foo] ...
object bar isa foo;
method my_visit_order(@bar):collection[foo] ...
etc.
method caching_visit(root:foo,
visit_accum:&(:foo):collection[foo],
visit_action:&(:foo):`T,
):void {
let to_visit := visit_accum(root);
to_visit.do(&(x:foo){visit_action(foo)};
}
(The precise interface here could be different in some of the details,
like if we wanted to start traversal from multiple roots, etc.)
Usage:
caching_visit(root, &(x:foo){
my_visit(x)
}, &(y:foo){
-- do something
});
First-class multimethods only buys you the freedom to leave out the first
closure:
caching_visit(root, my_visit, &(x:foo){
-- do something
});
Maybe I'm just used to writing these kinds of closures for Cecil control
structures, but this doesn't seem to be a big deal.
On the other hand, lexically scoped methods that dispatch would make a
meaningful difference, because you could define my_visit locally rather
than at the top scope.
~k.lee
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Sat Mar 03 2001 - 12:32:04 PST