Kevin Reid wrote:
> I've thought of two possible solutions so far:
>
> 1. Starting from EMethod(..., "a", ...), scan its children for
> occurrences of NounExpr("foo") and reject any which bind it. This
> would reject more than it needs to.
>
> 2. Switch to a pre-processing stage (instead of the incremental
> operation of a zipper) to assign an identity (or a mutable analysis-
> information field, equivalently) to each variable binding and all of
> its uses, and add upward references (like in the zipper) to each
> node; this would make the is-this-foo-that-foo test a simple comparison.
> At the moment, the second option seems attractive; tying uses to
> definitions of variables in a generic fashion should be useful for
> other types of analysis. And since this is strictly analysis, not
> transformation, I don't need the modify-without-mutation function of
> a zipper. The only reason I haven't done that yet is I think zippers
> are neat (and there might be other uses for an established zipper
> over E ASTs).
The second option is called "Barendregt's convention". It's very common
to use this convention in program analysis; you would be in good company.
--
David-Sarah Hopwood
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang