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


From: "Hugh Sasse Staff Elec Eng" <hgs@dmu.ac.uk>
>
> On Wed, 21 Nov 2001, Bill Kelly wrote:
>
> > I agree (and I think (??{  }) is the worst of the lot unfortunately).
> > But if a constraint is maintaining standard regexp compatibility,
> > there don't seem to be a great many opportunities to introduce a
> > "clean" looking way of naming things into the syntax.
> 
> Well, one way to do it would be to 'take a leaf from' the x modifier,
> which allowed spaces in regexps to be ignored.  /.../r isn't used
> yet, is it?  These could be Ruby extended regexps....

Just to clarify, are you thinking that /.../r would "enable" the
hypothetical (*name:pattern) extension?  Or that by using /r we
would have the means to bend other syntax rules (as in /x) to come
up with a new (clearer|less intrusive) method of specifying the
named extensions syntactically?

[...]
> >
> > (*some_meaningful_name:the pattern)
> 
> I like this one, it reminds me of (* comments in Pascal *)  :-)
> But mainly the * is illegal here in all regexps, so is clearly doing
> something different.  And that goes back as far as ed, sed, and awk.
> 
> 
> > (+some_meaningful_name:the pattern)
> > ({some_meaningful_name}the pattern)
> 
> You may really want to match braces within brackets, so I think
> that would trip Rubyists up quite a bit.

OK.  Just to state the obvious I believe you're saying even though
we'd already have to (\{...\}) if we wanted to match braces within
brackets... it *still* might be confusing to if braces took on a
special meaning at the beginning of a group.  (I don't disagree;
just trying to make sure I understood your point, while reiterating
that braces do already have to be escaped.)

[...]
> > ...which in context might look like:
> >
>    foo(*followed-by:bar)
>    etc
>    [...]
> >
> > ...the first two (out of just these five anyway) look to me personally
> > perhaps a little more agreeable than the latter three.
> >
> > Anyway I hope this has at least succeeded in giving some background as
> > to what we're up against syntactically in terms of adding extensions
> > to the standard regexp syntax.
> 
> That is why it may be worth breaking out with /..../r, but these
> suggestions are good.

Any thoughts as to how a /..../r expression might look? . . . utilizing
whatever /r does, that is?  :-)


Regards,

Bill