I will try create a proof-of-concept ANTLR parser then.
See how it goes. If filters are a show stopper, then perhaps there is
a bit different way of creating them that will work better.
For some reason I think performance might improve as well.
Or perhaps I am just an optimist :)
On 7/24/07, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
>
> Problem is, I'm pretty sure it's not a context-free grammar. I'm no
> expert on parsing and state machines and such, but even if we got rid of
> the indentation (which is how Python and I believe Yaml are parsed), I'm
> pretty sure stuff like filters throws a big bone into everything. I
> could be wrong, though...
>
> Either way, it would certainly be possible to make a real parser at
> least for tags.
>
> - Nathan
>
> Tom Stuart wrote:
> > The general problem is more fundamental than that -- finite state
> > machines (i.e. the programs encoded by regular expressions) lack the
> > computational power to do unlimited parenthesis balancing -- but
> > regardless, non-greedy matching will fail whenever parentheses are
> > nested more than one level deep:
> >
> > %foo{:bar => { ... }}
> >
> > Here we'd match the first '{' with the first '}' (which isn't its
> > partner) so it's just the opposite problem.
> >
> > I don't know off the top of my head whether people typically use
> > nested hashes in tags, but in the general case they do.
> >
> > (A thousand beers to the person who rewrites Haml and Sass to use
> > Ragel and a real parser.)
> >
> > Cheers,
> > -Tom
> >
> >
> > >
> >
> >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
