develooper Front page | perl.perl5.porters | Postings from May 2003

Re: [perl #22182] regular expression bug (design limitation?)

Thread Previous | Thread Next
From:
Edward Peschko
Date:
May 14, 2003 17:40
Subject:
Re: [perl #22182] regular expression bug (design limitation?)
Message ID:
20030514150705.B950@mdssirds.comp.pge.com
On Tue, May 13, 2003 at 03:36:07PM -0000, A.Bergman (via RT) wrote:
> 
> On tisdag, maj 13, 2003, at 01:35 Europe/Stockholm, 
> esp5@mdss03.comp.pge.com (via RT) wrote:
> 
> >
> > The following script dumps core on both perl-5.8.0 and perl-5.6.1 - 
> > it's probably
> > due to a design limitation in the regular expression engine, and I'm 
> > interested to
> > hear any workarounds.
> >
> >
> >
> 
> There regex engine should be rewritten to be iterative instead of 
> recursive, authority has said that this should be simple but noone has 
> stepped up with patches.

I was thinking about this a bit, (especially in conjunction with 'push(@INC, \&ref)), 
and was wondering how easy/acceptable it would be to extend the regex engine (yet again) 
- in a way that would be relatively painless..

I'd like to be able to define a coderef that looks like the following:

my $_coderef = sub { my ($text) = @_;
					# text starts from position at which regular expression last 
					# matched.
					# do something with $text, including regular expressions to modify
					# pos($text);
					# change pos so that the regular expression 'picks up' where the 
					# sub left off (ie: pos).
			}

Then people could write stuff to do particularly difficult regular expressions using 
Inline::C, and you could say:

if ($varb =~ m"($balanced_parens)")  # is a C call.
{

}

which IMO is far more intuitive (and cleaner) than anything to do with (?...).

Ed

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About