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


From: "Hugh Sasse Staff Elec Eng" <hgs@dmu.ac.uk>
>
> On Thu, 22 Nov 2001, Bill Kelly wrote:
> 
[...]
> > 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.

Oh, no, sorry, I was just trying to understand what you might have
envisioned expressions written with /r looking like.

Let's say without the /r, Ruby regexps work precisely as they do now,
without any of the extensions we've been positing.  What I was wondering
was, would the addition of /r,

  1)  Enable (make available) the (*name:pattern) type syntax?

  2)  Make available some other, as-yet undiscussed modification
      to the syntax?

  3)  . . . None of the above?  :-)


[...]
> > 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! :-)

No, please continue, I don't mean to be a pain, your contributions
are most appreciated.  It isn't *my* language either.  :-)


[...]
> > 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...

Ah, I just wondered if you might have had a specific notion of how
you'd like to see regexps written, using the /r extension?  (By written
I don't mean the behind-the-scenes implementation of the engine :)
But rather, /what do I look like/r ?


Regards,

Bill