Re: "Regular expressions" for stack automata?

ilya@math.ohio-state.edu (Ilya Zakharevich)
24 Sep 1999 22:57:43 -0400

          From comp.compilers

Related articles
"Regular expressions" for stack automata? Marko.Makela@HUT.FI (Marko =?ISO-8859-1?Q?M=E4kel=E4?=) (1999-09-10)
Re: "Regular expressions" for stack automata? Marko.Makela@HUT.FI (Marko =?ISO-8859-1?Q?M=E4kel=E4?=) (1999-09-16)
Re: "Regular expressions" for stack automata? world!cfc@uunet.uu.net (Chris F Clark) (1999-09-20)
Re: "Regular expressions" for stack automata? ilya@math.ohio-state.edu (1999-09-24)
Re: "Regular expressions" for stack automata? qjackson@wave.home.com (Quinn Tyler Jackson) (1999-10-04)
| List of all articles for this month |
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Newsgroups: comp.compilers
Date: 24 Sep 1999 22:57:43 -0400
Organization: Department of Mathematics, The Ohio State University
References: 99-09-030 99-09-050
Keywords: parse

[A complimentary Cc of this posting was sent to Marko Mäkelä
<Marko.Makela@HUT.FI>], who wrote:
> The regular expression "\E(bal)" defined by
>
> e(bal)/[^`']*(`\E(bal)')*[^`']*/
>
> matches any string balanced with respect to single quotes "`" and "'".


In Perl (starting from 5.005_53) it is


    $bal = qr{ [^`']* ( ` (?p{ $bal }) ' )* [^`']* }x;


but in this form it is not very efficient. Probably you want
something like


    $bal = qr{
(?>
(
(?> [^`']+ )
                                  |
                                      ` (?p{ $bal }) '
                                  )*
                          )
}x;


which would not backtrack.


> By the way, I was very impressed that the regular expressions have
> remained practically unchanged for a so long time.


Then you did not follow...


> John> [Many implementations of REs such as GNU grep extend the
> John> REs in interesting ways with backreferences. -John]
>
> True, but I haven't seen anything like the \E(re) construct of QED
> anywhere, and \1..\9 cannot express the same thing. I wonder how well
> Perl regular expressions would perform with this construct. I would
> expect especially the non-greedy closure operators *? and +? to be
> utterly inefficient with this construct.


Why?


Ilya


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.