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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
