Front page | perl.perl5.porters |
Postings from February 2011
On 02/24/2011 08:37 AM, Tom Christiansen wrote: > Karl Williamson wrote: > >>> Could we add the underscore as a no-op flag for any of these >>> operators, just like how it's interpreted in numeric literals? >>> Then you could write qr//modularise_apex # :-) > >> ++ > >> I'll do this myself in 5.16 unless there is objection. > > I can't see any objection. I think it would be a good thing. > It is super- reasonable to break up long strings of garbable > nonsense with de-facto whitespace for cognitive chunking. > I could see myself doing like > > while ( /pattern/aa_smix_cg ) > > or some other arrangement that clumps related things together. > > I have another question, though. > > Is it perhaps time to consider some mechanism by which one can > optionally use a denotation that's longer and more meaningful than > singleton letters? While C<use re "/sx"> isn't too bad, there are > starting to be so many /oodles of these that I begin to have those > old embarrassments of: > > * Being restricted to one-letter variables in old BASIC. > > * One-letter "-x" options in standard Unix commands > instead of the "--long-opts" now often seen. > > * Perl's infamous single-punctuation variables that were > so bitterly berated before we got C<use English>. > > I am beginning to see all these C<s/super/duper/mxyzptlk> options > in a similar, and rather dim, light. Is this just me? I bet not. > > Long regex option/identifiers would slot in at three different places: > > 1. the "use re '/flags'" pragma > 2. inside (?flags), (?onflags:pat), (?flags-flags:pat) etc. > 3. postfix modifiers for all of qr//, m//, s/// -- and also tr///. > > There are syntactic or tokenizing concerns in all of those, although > #1 shouldn't be rough but #3 might be. I don't know how to approach > those second two. Any ideas? > > thanks, > > --tom > I can't answer the question about how hard it is without a concrete syntax proposal.Thread Previous | Thread Next