Front page | perl.perl5.porters |
Postings from August 2010
H.Merijn Brand wrote: > On Wed, 04 Aug 2010 22:09:57 -0600, karl williamson > <public@khwilliamson.com> wrote: > >> demerphq wrote: >>> On 4 August 2010 15:38, karl williamson <public@khwilliamson.com> wrote: >>>> Aristotle Pagaltzis wrote: >>>>> * Ben Morrow <ben@morrow.me.uk> [2010-08-01 22:35]: >>>>>> My alternative suggestion was to introduce a new grouping >>>>>> construct, which I tentatively called (?~sixm:) (I don't much >>>>>> like that, but there aren't many alternatives at this point), >>>>>> which *does* do what you expect; and use that for >>>>>> stringification instead. That way we change the stringification >>>>>> once, now, and then never again. >>>>> I’m unsure about how good an idea that is. >>>>> >>>>> Presumably the defaults can change in a future version of Perl, >>>>> in which case a stringified pattern that uses this syntax will >>>>> mean different things on different Perl versions. In some cases >>>>> this will even magically do what you want, but it could equally >>>>> be a pitfall. >>>> FWIW, I have given this some thought, and came to the conclusion that Perl >>>> is almost certainly never going to change the defaults, because of the >>>> backward compatibility issues. >>> Except that its been discussed many times that being able to specify >>> the default flags in a lexically scoped manner would be a useful >>> feature. So while it might be true that /perl/ will not change the >>> default flags, it is quite conceivable that perl will provide the user >>> a way to do so. >> Certainly, but it's not relevant here, as this construct would not be >> affected by those. (I now think a period is better than an underscore, > > Assuming that the . is the same as the _ in the other thread, ... > > No, as it is not a syntax error at the moment: > > $ perl -we'$a =~ m/foo/i_Cu' > Bareword found where operator expected at -e line 1, near "m/foo/i_Cu" > syntax error at -e line 1, next token ??? > $ perl -we'$a =~ m/foo/i.Cu' > Useless use of concatenation (.) or string in void context at -e line 1. > Name "main::a" used only once: possible typo at -e line 1. > > in the bottom example, the . is interpreted as a concatenation. > >> so will use that in the examples.) (?.:foo) would mean this cluster >> does not inherit the surrounding flags, but uses the /perl/ default >> ones. (.x:foo) means this cluster does not inherit the surrounding >> flags, but uses the /perl/ default ones, but also the x modifier is >> selected, whether or not it is a /perl/ default. >> >> Whatever the user has chosen to be the default, it will be shown in the >> stringification iff it differs from the /perl/ default. > You misunderstood. We are talking about two different things. One thing is new regex modifiers and what they should be; that is a different thread. The other thing in this thread is using some character to symbolize "use the default options" in the stringification of a regex. What I was proposing was that the latter be a '.'. It would only be valid immediately after the '?' in the (?.posflags-negflags:foo) construct. It would not be valid in suffixes. I had originally proposed it being an underscore, Ben, whose idea it was, thought of a tilde. This is not related to the idea of using an underscore in "m/foo/i_Cu" to add clarity to the suffix (and perhaps infix) modifiers, except that that if we have underscore mean two different things, it would be confusing, so I'm withdrawing my original suggestion in favor of using a dot instead, which is illegal currently in the proposed context.Thread Previous | Thread Next