Hi Kaspar, Many thanks for your fast response.
I already discovered the use of .as(...) as a handy tool to make a kind of AST. Working with Parslet is part of a hobby (project) as I am writing a Lineair Genetic Program (in which a lineair representation of programs is considered as an advantage compared to the traditional tree representation used in genetic algorithms.) The problem I am trying to solve now is to translate each one of the initial decision rules to a linear program structure which should be sets of three-address codes. Today I started to experiment with the Sequence (symbol) and Subtree(symbol) patterns. Although, I am not yet familiar with them I was happy to receive your example of the redesigned transformation rules of my problem. I am sure they will help me to improve my understanding of the Parslet transformation game. Regards, Thiel Op 13-5-2011 16:43, Kaspar Schiess schreef: >> I hardly can't believe that this is the way I should have to work with >> Parslet! >> >> My question is how to define transformation rules in a smart way? My >> guess is that I'm not using the right matching features >> like, for example, sequence or subtree? >> > Hi Thiel, > > I am guessing that your grammar has a problem. It must be possible to > add/remove .as(...) so that you get a tree more like the one portrayed > here: http://kschiess.github.com/parslet/get-started.html (down below). > > Specifically, you should have a left hand side of 'a' and a right hand > side that contains the tree for 'b + c'. This way, recursive matching > makes actual sense. > > The tree you have could be transformed using something like this, > although my mind rebels against the loss of associativity between 'a' > and '+b', '+c': > > transform = Parslet::Transform.new do > rule(:factor => {:ident => simple(:x)}) { x } > rule(:plus => simple(:op), :term => simple(:x)) { [op, x] } > rule(:term => simple(:x)) { x } > rule(:result => subtree(:something)) { something } > end > > regards, > kaspar > >
