This might actually be more fixable once we get Oniguruma as the Regex
engine as there's some nifty tricks you can wrt to named groups called
the "Tanaka Akira special" which you can see at section 9 of
http://www.geocities.jp/kosako3/oniguruma/doc/RE.txt
At least I know what is going wrong now, I'll have to keep it in mind,
its a really peculiar bug to pick up on unless you know its there.
Geoff
On Jul 25, 7:37 am, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
> Really, all we'd need to do to get the tag working is to have an
> extract_attributes method that grabs everything between the first '{'
> and the balancing '}'.
>
> - Nathan
>
> Tom Bagby wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---
