Performance will probably deprove since the current naive regex
implementation does less work than is really necessary to parse
correctly.  Also, templates are parsed only once, so parser
performance doesn't really matter much in the grand scheme of things.

I'm happy to see all proofs of concept, but I think an ANTLR parser is
probably overkill.  In fact, a 'real parser' for most of Haml is
almost certainly overkill.  I've been messing around with a relatively
simple ragel machine (http://www.cs.queensu.ca/~thurston/ragel/) just
for tag parsing.  I think even that is too much.  A simple 'real
parser' for tags written by hand would be quite short.  It's probably
worth it to write it that way just to avoid dependencies on external
build tools/languages.  But playing with parser toys is very fun.

Ever the pessimist,
Tom

On Jul 24, 11:23 am, Evgeny <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to