develooper Front page | perl.perl5.porters | Postings from August 2010

Re: qr stringification: why are xism always present? I'm worried about backward compatibility

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
August 5, 2010 12:31
Subject:
Re: qr stringification: why are xism always present? I'm worried about backward compatibility
Message ID:
20100805213125.6f8efaee@pc09.procura.nl
On Thu, 05 Aug 2010 12:31:42 -0600, karl williamson
<public@khwilliamson.com> wrote:

> H.Merijn Brand wrote:
:
> > 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.

Thanks for clearing that up. I understand and agree

-- 
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

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