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

[Jean-Michel Hiver]

> > 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.

Yes but no. I think Petal should be able to use a hint if it's
available, otherwise try what's most likely.

For example:

  self/foo()      - method
  self/132        - most likely array, possibly hash
  self/-foo       - hash
  self/{foo}      - hash
  self/foo        - most likely method, possibly hash
  self/foo args   - method
  self/[123]      - array

This way you make it possible to hint the code generator, but if you're
feeling lazy it would be fine, too.


> Are you proposing to skip the can() tests that are currently done?

No I was just writing down an idea, I never said that it would be
correct code :)


> 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.

I disagree. It's quite cool to be able to replace an attribute by a
method if necessary and avoid touching the templates. I think this is a
good thing.


> > 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.

And that's what I should have done since the beginning. Ah well, you've
been smarter than me on that one :)


> > 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

Well, I don't really know about this. Potentially, modifiers can do
anything, so it doesn't seem to be that they should be in the expression
parsing syntax.


> 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...

That's right. But then if the modifiers are in the grammar you loose
quite a lot of flexibility. So I don't really know what to do about
this...

I think I'll live with this limitation for now. Parse::RecDescent has
the ability to modify its grammar at runtime, so I'm sure we'll be able
to lift the problem at some point by getting Parse::RecDescent to call
the plugin which would then modify Parse::RecDescent's grammar.

Sounds like a crazy bit of parsing... but hey, as Perl hackers we should
be pleased with all this mad complex changing-at-runtime hairy syntax
munging :)


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

Cool, that's exactly what I want. Thanks to your example I'm starting to
get used to Parse::RecDescent.


Best Regards,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver at mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/