From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2001-11-22T03:09:56+09:00
Subject: [ruby-talk:26046] Re: ANN: regex engine development (was: Re: Why not xmlparser?)

On Thu, 22 Nov 2001, Bill Kelly wrote:

>
> 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?

I'm not sure what you are asking : are these not the same -- "enabling
a feature" or "allowing new rules like /x does" ?
 I'm not really talking about how it is implemented, if that is the
difference between these: the implementation of regexp engines is
something I know too little about.
>
> [...]
> > >
> > > (*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;

I think so: they are already used for
   /x{3,5}/ # 3..5 x chars
and
   /#{a+b}/ # substitute results of a+b
so ({thingy}...) might be too much.
OTOH it might be consistant with braces being special, but I don't like
it so much.  But it isn't *my* language - good people, have your say! :-)

> just trying to make sure I understood your point, while reiterating
> that braces do already have to be escaped.)
>
	[...]
> > > 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?  :-)

Well, pretty much like a normal regexp, but clearer with these features.
The Ruby way seems to be "keep things familiar, but improve on them
where you can", so I'm not suggesting regexp engines be directly coded
in embedded FORTH, or some such dramatic change! :-)  Or have I missed
the point of this question...
>
>
> Regards,
>
> Bill
>
>
	Hugh
>