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

[Fergal Daly]

On Wednesday 11 June 2003 1:48 pm, Jean-Michel Hiver wrote:
> 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.

I don't think we're arguing on this point. That's what I'm doing.

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

I agree on that, I'm not suggesting templates should have to specify object or 
hash access. thing/name should continue to work whether thing is an object or 
a hash.

I'm saying that maybe it would be good to prevent people accessing an object 
as a hash. That is, if $has->{thing} is an object then thing/name _must_ be 
treated as $hash->{thing}->name(), not $hash->{thing}->{name}.

The template doesn't have to know in advance if $hash->{thing} will be an 
object or a hash but if it is an object then it _isn't_ a hash (even though 
it's a blessed hash). The templates that would break in this scheme are the 
ones which treat thing as an object in one place but as a hash in another, 
which is bad design to start with.

It would also improve error checking. Imagine an object for a person's details 
with a method getName. In the template you have a typo "person/getNam". 
Currently we will look at person, check if getNam is an available method, see 
that it's not and so fall back to hash access with person->{getNam}. Whereas 
without the can() tests Petal would try to do person->getNam and it would 
die, which is a good thing.

It's a question of whether people should be able to break the object 
encapsulation _without_ specifically asking to (by using the hash hint 
syntax). Strict object people would say you shouldn't even be able to ask.

I'm not really convinced either way. The current way is more convenient but is 
slower due to lots of can() call and can hide errors in the template. Maybe 
it should be configurable. Of course maybe it would be better to work on 
important stuff ;-)

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

I think I get you, I was getting mixed up between modifiers and expression 
types. So path:, string:, not:, exists: are not modifiers but true: is. I've 
removed true from my grammar.

If a modifier is just a name, followed by a ":" followed by an expression, 
then a rule like

modifier_name: /[a-z_][a-z_0-9]*/i

modifier: modifier_name ":" expr {
	wrap_modifier($item{name}, $item{expr});
}

should be able to handle them. Modifiers don't actually change how the rest of 
the expression is parsed, or do they? If they do then we'll never be able to 
compile them in advance without each modifier knowing how to compile itself 
too,

F