From: Bill Kelly <billk@...>
Date: 2001-11-22T03:10:41+09:00
Subject: [ruby-talk:26047] Re: ANN: regex engine development (was: Re: Why not xmlparser?)


From: "Ciaran McCreesh" <keesh@users-dot-sf.net>
>
> Hugh Sasse Staff Elec Eng wrote:

[...]
> >    foo(*followed-by:bar)
> 
> Nice. I'm not sure that a colon is a good idea though -- seems to be used 
> as a quote char fairly often. How about /foo(*followed-by*bar)/r or, if the 
> /x modifier is used, /foo (*followed-by* bar)/rx, which is maybe more 
> readable?

Wow, given the relative ubiquity of (?: ... ) in regexps I'd have thought
colon an unlikely choice for a quote character.

That  /foo (*followed-by* bar)/rx  is starting to look pretty nice I
must say.

[...]
> Whilst we're on the topic, might I also suggest named capturing groups? 
> Using backreferences is a pest if an expression has to be changed / merged, 
> since all the numbers go wrong. For example,
> 
>   /(*capture:my_word*[a-zA-Z]+) +(*backref:my_word*)/r
> 
> could match doubled up words (yeah, I know, there's a colon...). Again, 
> it's a readability thing mainly. Okay, it would be a performance hit when 
> used, but if it's only enabled when necessary it shouldn't be that bad...

Yes, I'd love to see this too.  First time I ran into it was in Python,
a few months ago.  Very nice...  Although Python uses (?P<my_word>...)
(and I'm not aware of how it handles backrefs to named groups), I'd been
toying with the idea of a syntax like:

  /(?@my_word:[a-zA-Z]+) +(?@my_word)/


N.B. I think the performance hit associated with named groups would be
negligible: a little extra work compiling the pattern, but presumably
no overhead during the match as the names would have been resolved to
fixed register locations during the compile. . . . Of course, we'd 
need to "copy them to a hash table" or whatever after the match.  But
the performance of the match itself shouldn't be affected, anyway.


Regards,

Bill