I may not be understanding the issue right, so if so ignore me.
Parslet transformations confuse me a bit, so I end up not actually using
Parslet transformations, but instead using the :as labels in a way such
that the parset-produced intermediate parse tree can be pretty easily
handled by my own just plain ruby code.
But I wonder if, even using Parslet transformations, you might do better
changing your labelling at the parsing stage, to give you something
closer to what you want for transformation?
I am parsing a grammar with some similar issues, but instead of winding
up with an intermediate parse tree like [IntegerLiteral, BinaryOperator,
IntegerLiteral], I wind up with one like:
binary_expression => {:first_operand => 'foo', :operator => '+',
:second_operand => 'bar'}
On 5/2/2011 12:30 PM, Ant Skelton wrote:
On Mon, May 2, 2011 at 5:20 PM, Kaspar Schiess <[email protected]
<mailto:[email protected]>> wrote:
Curiosity killed the cat ;) Have a look at
parslet/pattern/binding.rb –
The right way to do this IMHO is to create a binding that only matches
the right kind of :bar!
Oh, interesting. How does it match a 'sequence()' directive in the
transform rule to a 'SequenceBind' object? Is it just string fu? Can I
add a FooBind object and start using 'foo()' in rules?
No other way for saying: Hey I didn't match. Because.. in a way, once
the block is executed, semantically parslet has a match.
Yeah that's what I figured, I wondered if there was any kind of
"actually, you know what....." undo mechanism.
> rule(SomeClass, SomeOtherClass) {...} # these classes are constructed
Or are you looking for a generalized Ruby class hierarchy transformer?
(Because I am ;))
Yeah, that one ;) I end up with a lot of entries like " [
#<IntegerLiteral: 0x....>, #<BinaryOperator: 0x....> ] " so what I do
is match generic sequences and figure out what to do in the
transformation block. It would be cool to be able to say:
rule(IntegerLiteral, BinaryOperator) {...}
cheers
ant
ant
