Who is interested in using the PAST optimization(and analysis) tools I am developing?

[Tyler Curtis]

For the Google Summer of Code this year, I'm implementing a set of
Parrot libraries for writing optimizations and analyses at the Parrot
Abstract Syntax Tree level. I've posted blog posts about my initial
thoughts about the designs of the two main libraries I'm planning to
develop(PAST::Walker[0] for simple traversal and PAST::Pattern[1] for
pattern matching). Expect another one this week about how the
implementation of PAST::Walker has gone so far and about something I
didn't realize at first would be needed: PAST::Transformer.

As I've been working so far, I've come across some complications and
unforeseen decisions that don't have obvious answers, and I expect
that this will continue. When I make these decisions(some examples
follows), I want to take into account the needs and desires of the
potential users of the libraries I'm writing. However, I don't really
know who amongst Parrot and HLL developers thinks they might use these
libraries. For this reason, in addition to feedback from anyone
interested on the following questions, I'd like anyone who is
interested in writing optimizations or analyses on PASTs to contact
me, either via the list, email off-list, or IRC so that, in the
future, I can specifically contact the potential users of my project
instead of spamming the list(although I will still mention any such
issues in my weekly blog post on parrot.org).

Note: I will fully explain PAST::Transformer in my blog post this
week, but for now: it's essentially PAST::Walker with the ability to
delete nodes or replace a node with a node of a different type. If you
want a more specific explanation, you can either wait for my blog
post, ask here on IRC, or just glance at the example of its use in my
branch[2].

The specific questions I have right now are:

1. Should PAST::Walker/PAST::Transformer traverse node attributes that
contain other nodes? For example, the 'viviself' and 'vivibase'
attributes of PAST::Var nodes can contain other PAST nodes.

2. Should PAST::Pattern attempt to pattern match in node-containing attributes?

3. Should I implement a method for deeply copying PASTs? Deeply
copying a PAST is tricky because PASTs can have cycles and the
generated code may break if you don't preserve that cycle. Because of
this, I am considering writing a sub(possibly named something like
PAST.deepCopy) to deeply copy PASTs in a cycle-preserving manner. Does
anyone think that they might have a use for keeping a copy of a PAST
after running a transformation on it?

4. bacek proposed an XPath-like syntax for pattern matching of
PASTs[3]. Would this sort of syntax for matching be helpful? Would it
be something you would like to have in addition to or instead of the
programmatic PAST::Pattern API I described in my blog post? Is there
any useful pattern matching that can't be done in XPath that could be
done with my proposed PAST::Pattern API?

[0] http://www.parrot.org/content/past-optimization
[1] http://www.parrot.org/content/past-pattern-matching
[2] http://trac.parrot.org/parrot/browser/branches/gsoc_past_optimization/examples/library/pasttransformer.pir
[3] http://irclog.perlgeek.de/parrot/2010-05-25#i_2364268
-- 
Tyler Curtis