It might end up bloating the engine but you could potentially load a
different set of regular expressions depending on the presence of the
Regexp::ENGINE constant or lack thereof and its value. It is
'Oniguruma' if when Ruby is using the Oniguruma regex engine.
Reckon I'll wait for Ruby 2.0 to come out :P should be easier all
round then.
Geoff
On Jul 25, 9:03 pm, Tom Bagby <[EMAIL PROTECTED]> wrote:
> Yes, that plus correctly ignoring {'s and }' that appear in strings
> since those can be unbalanced. My rambling earlier was a long way of
> saying that something simple like this is all that is necessary.
>
> - Tom
>
> On Jul 24, 11:37 pm, 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
-~----------~----~----~----~------~----~------~--~---
