develooper Front page | perl.perl5.porters | Postings from February 2012

Re: [perl #109798] '/e' regexp modifier is not recognized by re pragma

Thread Previous | Thread Next
From:
demerphq
Date:
February 5, 2012 09:55
Subject:
Re: [perl #109798] '/e' regexp modifier is not recognized by re pragma
Message ID:
CANgJU+WbbGGFgeaE2_7mU7A=SP4_64xnak5R=jGmncuKV-jeOA@mail.gmail.com
On 5 February 2012 02:24, Tom Christiansen <tchrist@perl.com> wrote:
> "Eric Brine via RT" <perlbug-followup@perl.org> wrote
>   on Sat, 04 Feb 2012 16:19:41 PST:
>
>> Also note that "e" is not mentioned in perlre. The regex flags
>> are (as listed in perlre): m, s, i, x, p, g, c, a, d, l, u.
>
> That's incorrect, and potentially misleading.
>
> With blank lines removed for brevity, these are
> the only pattern modifiers:

Please Tom, it is very difficult to discuss things that are a mass of
pod extracts. Next time either render the POD and then paste it as
text, or don't use POD at all.

>    =head2 Pattern Modifiers
>    =begin table picture Regular expression modifiers

....

>
> That's all.  Those apply to patterns.
>
> These flags, however, apply to the match operator, which is different:
>
>
>    =head2 The m// Operator (Matching)

....

> Here are the s/// flags:
>
>
>    =head2 The s/// Operator (Substitution)
...

> And tr/// has its own as well:
>    =begin table picture tr/// Modifiers

tr/// has nothing to do with the regex engine, IMO it has no place in
a discussion about regular expressions.
>
> See?  Four distinct sets of flags.

I personally would analyse modifiers in a very different way.

As far as I am concerned there are only three types of regex modifier.

1. Modifiers which change the semantics of how a pattern is interpreted

/m /s /i /u /d /l /a

2. Modifiers which change the behavior of the matching process or how
a pattern is compiled

/x /o /g /c /p

3. Modifiers which change the behavior of the substitution process.

/e /ee /r

>> (I find this very odd that p, g and c are regex flags instead
>> of match substitute operator flags, but they are are.)
>
> You should find it odd, because they aren't.

I don't really understand this analysis. This is a new feature, what
it does or not do is hardly definitive in any way.

>    $ perl -E 'use re "/e"; say "ok"'
>    Unknown regular expression flag "e" at -e line 1
>    ok
>
>    $ perl -E 'use re "/g"; say "ok"'
>    Unknown regular expression flag "g" at -e line 1
>    ok
>
>    $ perl -E 'use re "/c"; say "ok"'
>    Unknown regular expression flag "c" at -e line 1
>    ok

>    $ perl -E 'use re "/p"; say "ok"'
>    ok


This one is pretty weird. It makes some sense, but I cant help but
wonder why someone would use this instead of using $` and $& and $'
directly.

> What's going on with the first three is that it isn't properly dying.
>
>    $ perl -Mwarnings=FATAL,all -E 'use re "/g"; say "ok"'
>    Unknown regular expression flag "g" at -e line 1
>    ok
>
> That's a bug.

Is it, it seems like it warns, which would be a deliberate action, so
I can only assume it is a feature.

> What's going on with the last one is more subtle.  /p can be
> embedded in a pattern with (?p), but it cannot be turned off
> once turned on.

Correct.

> Anyway, probably perlre should be clearer (read: more correct)
> about the s/uper/man/mxyzptlk flags, and that jazz.

Erm, maybe, but personally I would not document it the way you did. It
makes sense as documentation for the individual operators, but IMO the
division I used is much closer to the internals.

cheers
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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