[Petal] [HELP] Anybody has experience with parsing?

[Fergal Daly]

On Wednesday 11 June 2003 10:46 am, Jean-Michel Hiver wrote:
> Your implementation is mostly interesting! I understand the interest of
> hinting the code generator on the type of expression that's being
> parsed, but on the other hand I really like Petal's ability to 'do the
> right thing' given an expression.

You could argue that Petal already includes hinting for methods but only 
methods which take arguments. So why not also allow it when for 0-argument 
methods. On my benchmark, hinting doubles the speed so I think it's a 
worthwhile option.

By the way, I'll post the benchmark code in a few minutes, you can decide how 
useful it is.

> I suppose ideally Petal should be able to do both... Also, maybe
> something 'like/this' could be turned into something like:
> 
>   do {
>       my $context = do {
>           $context = $Context;
>           ($context =~ /=/) ? $context->this() : $context->{this};
>       };
>       ($context =~ /=/) ? $context->like() : $context->{like};
>   };

Are you proposing to skip the can() tests that are currently done? That might 
be a good idea. Effectively the can() tests allow you to look inside an 
object if it doesn't have the right method, but this goes against object 
orientation. The version above prevents you from accessing an object as a 
hash which is probably a good thing but it may break existing templates.

> It could be then be brutally dumped in the code that's generated...

That's exactly what Text::TAL and the rest of Text::Engine does at the moment.

> Also, I don't think that the 'some_modifier:' syntax should be included
> in the Parse::RecDescent grammar because it seriously limits
> extensibility. But I would like to see modifiers produce code as well.

I was going to argue against this because I thought it impossible to parse

try/this|then/that|and/finally|string:not found

but then I realised it's ok. I'll remove the | handling from the grammar and 
move it into Perl code.

Hold on, I just though of another problem, if you move the modifiers out of 
the parser then you can't do this

string:hello {uppercase:person/name}

so maybe the modifiers need to be in the grammar...

> For example, 'false: like/this' could become something like:
> 
>   not do {
>       my $context = do {
>           $context = $Context;
>           ($context =~ /=/) ? $context->this() : $context->{this};
>       };
>       ($context =~ /=/) ? $context->like() : $context->{like};
>   };

That's exactly what Text::Engine will generate (except it will include the 
can() tests)

fergal at whizzo:~/my/projects/tal> examples/comp "false:like/this arg"
expression: false:like/this arg
(! $hash->{"like"}->this($hash->{"arg"}))

Plugins can work quite easily by simply wrapping the generated code in a call 
to the process function. So assuming

$Petal::Hash::MODIFIERS->{'uppercase:'} = 'MyPetalModifier::UpperCase';

then

uppercase:like/this arg

becomes

MyPetalModifier::UpperCase::process($hash->{"like"}->this($hash->{"arg"})

Finally, I forgot to mention in the last mail that your example of a "major 
limitation" - not handling

self/method ${self/other_method ${self/yet_other_method}}

already works in Text::TAL::TALES. Using Parse::RecDescent made it easy (in 
fact it made it harder not to behave like that!)

F