[Petal] Modifiers and variables

[Steve Purkis]

On Aug 19, 2004, at 12:18, Fergal Daly wrote:

> On Thu, Aug 19, 2004 at 11:42:05AM +0100, Jean-Michel Hiver wrote:
>>
>>>> I see. Well, I wouldn't adding a base class (i.e. Petal::Plugin)
>>>> which would be the recommended method to implement new modifiers, 
>>>> and
>>>> then cabling existing modifiers onto Petal::Plugin.
>>>
>>> I say, what a brilliant idea! :-)
>>
>> Which takes us to the problem of the syntax. We need to come up with a
>> sort of grammar for the parser in this base class. Any ideas?
>
> You could get fancy and use something to generate a parser from a 
> grammar, I
> wrote a Parse::RecDescent grammar for an extended TALES last year but
> there's a large overhead parsing like that every time the expression is
> ecountered, it only makes sense if you are going to parse and compile 
> it
> along with the template then use the compiled version at run time.

Compiled templates make a lot of sense, I wouldn't discount this option.


> What would be useful is to break out a parse_args routine (as in my 
> patch)
> or even a parse_one_arg routine. Make these handle an array of tokens. 
> Add
> wrapper versions that take a string, tokenise it, pass it in to one of 
> the
> above, these would be useful in modifiers.

Agreed.


> parse_one_arg kind of exists already in that it's just hash lookup 
> however
> what you cannot easily do is handle something that looks
>
> mod:some/expr some stuff for the mod to figure out
>
> because the modifier cannot (in general) figure out where the first 
> argument
> ends.
>
> So what you really need is a parse_one_arg which tries to use the 
> start of
> the string as an expression, consuming as much as possible but also 
> gives
> you back what it couldn't use. Then you could easily do
>
> if: a then b elsif c then d else e

sounds good.


> and parse it like
[snip]
> One problem with the above is that the "then" expression gets 
> evealuated
> even if the "if" expression is false, this is unavoidable because Petal
> currently cannot parse without also evaluating,

Ah, that might mean some performance hits.  Even unexpected behaviour 
(if objects change state in the background).

Maybe some rethinking Petal's parsing engine is in order?

-Steve