Re^2: Regex and question of design

grinder++, What a great module.

When you use tracking to see which regex matched does it still compile to one regex internaly ? The docs say:

track(0|1)
Turns tracking on or off. When this attribute is enabled, additional housekeeping information is inserted into the assembled expression using ({...} embedded code constructs. This provides the necessary information to determine which, of the original patterns added, was the one that caused the match.
$re->track( 1 ); if( $target =~ /$re/ ) { print "$target matched by ", $re->matched, "\n"; }
[download]
Note that when this functionality is enabled, no reduction is performed and no character classes are generated. In other words, brag|tag is not reduced down to (?:br|t)ag<code> and dig|dim is not reduced to <code>di[gm].

so I infer it it not as optimised as a non tracking version but still better than the looping solution ?

If there are two regexen in the list that match does it return the first, last, all or an indeterminate selection of the above ?

Cheers,
R.

Pereant, qui ante nos nostra dixerunt!

Comment on Re^2: Regex and question of design Select or Download Code

Replies are listed 'Best First'.
Re^3: Regex and question of design by grinder (Bishop) on Apr 14, 2005 at 12:53 UTC
When you use tracking to see which regex matched does it still compile to one regex internaly Yes. not as optimised as a non tracking version but still better than the looping solution ? It has the same behaviour insofar as at any point during a tracked pattern match, the "degrees of freedom" the engine has available to try is the same as for an ordinary assembled pattern. It's just that the tracked pattern is stuffed full of `(?{...})` zero-width eval assertions. If there are two regexen in the list that match does it return the first, last, all or an indeterminate selection of the above ? For a given target, the same path through the pattern will always be followed. In that regard it is perfectly deterministic, it is just that it is sometimes hard to determine in advance what that will be. It sort of makes sense if you squint hard enough. Consider: `#! /usr/local/bin/perl -w use strict; use Regexp::Assemble; my $re = Regexp::Assemble->new(track => 1) # remember to double up your backslashes ->add( '^X\\d+' ) ->add( '^X\\d\\d' ) ->add( '^\\sX\\d\\d' ) ->add( '^X\\d\\d' ) ->add( '^X\\d' ) ; while( <DATA> ) { chomp; print $re->matched, " matched <$_>\n" if $re->match($_); } __DATA__ XY1 X234 X56 X4 Z0 X77` [download] This produces: `^X\d\d matched <X234> ^X\d\d* matched <X56> ^X\d\d* matched <X4> ^\sX\d\d matched < X77>` [download] But I would stress above all that the list of patterns in this case is in need of reformulation anyway. Hmm, in fact, this is very interesting. With a suitably exhaustive population of target test stings, you could use this approach to weed out "can't happen" patterns. Thank-you for asking this question! I might recycle some of the ideas in this thread into examples for the module distribution. - another intruder with the mooring in the heart of the Perl	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Regex and question of design
by grinder (Bishop) on Apr 14, 2005 at 12:53 UTC

When you use tracking to see which regex matched does it still compile to one regex internaly

Yes.

not as optimised as a non tracking version but still better than the looping solution ?

It has the same behaviour insofar as at any point during a tracked pattern match, the "degrees of freedom" the engine has available to try is the same as for an ordinary assembled pattern. It's just that the tracked pattern is stuffed full of (?{...}) zero-width eval assertions.

If there are two regexen in the list that match does it return the first, last, all or an indeterminate selection of the above ?

For a given target, the same path through the pattern will always be followed. In that regard it is perfectly deterministic, it is just that it is sometimes hard to determine in advance what that will be. It sort of makes sense if you squint hard enough. Consider:

#! /usr/local/bin/perl -w

use strict;
use Regexp::Assemble;

my $re = Regexp::Assemble->new(track => 1)
    # remember to double up your backslashes
    ->add( '^X\\d+' )
    ->add( '^X\\d\\d*' )
    ->add( '^\\s*X\\d\\d*' )
    ->add( '^X\\d\\d' )
    ->add( '^X\\d' )
;

while( <DATA> ) {
    chomp;
    print $re->matched, " matched <$_>\n" if $re->match($_);
}

__DATA__
XY1
X234
X56
X4
Z0
 X77
[download]

This produces:

^X\d\d* matched <X234>
^X\d\d* matched <X56>
^X\d\d* matched <X4>
^\s*X\d\d* matched < X77>
[download]

But I would stress above all that the list of patterns in this case is in need of reformulation anyway. Hmm, in fact, this is very interesting. With a suitably exhaustive population of target test stings, you could use this approach to weed out "can't happen" patterns.

Thank-you for asking this question! I might recycle some of the ideas in this thread into examples for the module distribution.

- another intruder with the mooring in the heart of the Perl

[reply]
[d/l]
[select]