Berkeley CSUA MOTD:Entry 30196
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/05/25 [General] UID:1000 Activity:popular
5/25    

2004/5/12-13 [Computer/SW/Languages/Perl] UID:30196 Activity:very high
5/12    Perl question, I want to replace nnn with xxx, ie, \nnnn -> \nxxx
        (that's a backslash followed by n, not a newline), s/nnn/xxx/
        gives me \xxxn!! What to do? I want the replace to change everything
        except a literal \n that should stay as is...
        \_ I think s/(\\n)?nnn/$1xxx/ will do it.  That's "match an optional
           backslash-n and nnn and replace nnn with xxx".
           \_ Alternatively, s/(?<!\\)nnn/xxx/ explicitly matches any "nnn"
              that isn't preceded by a backslash.  You may or may not find
              this more intuitive.
                \_ ?<! is the syntax? how weird.
                   \_ It's based on the older syntax of ?!, which looks ahead
                      in the string: /foo(?!bar)/ matches foo but not foobar.
                      When they added the ability to look behind, matching
                      bar but not foobar, /(?<!foo)bar/ seemed like the least
                      bad choice.

                      Yes, it's a mess.  The tentative perl6 syntax for this
                      is /<!after foo>bar/, where <!after foo> is read "not
                      after foo" and means "assert that the current position
                      in the string is not immediately after something that
                      matches foo".  --mconst
                      \_ I must say the introduction of actual English keywords
                         (in regexps, no less!) instead of line noise is a
                         philosophical novelty for Perl.  Or maybe they added
                         so much functionality that the pigeonhole principle
                         hit them pretty hard, and they had no choice. -- ilyas
                         \_ Heh.  You might actually enjoy reading some of
                            Larry Wall's rationale for the new regexp syntax;
                            it includes quotes like:

                                It should not be considered acceptable to
                                define new constructs that contain a plethora
                                of punctuation, but we've become accustomed
                                to constructs like (?<=...) and (??{...}) and
                                [\r\n\ck\p{Zl}\p{Zp}], so we don't complain.

                            Check out http://csua.org/u/7af starting at "First, let
                            me enumerate some of the things that are wrong
                            with current regex culture."  --mconst
                            \_ But I *like* line noise!  It makes me look
                               brilliant at work.
Cache (3506 bytes)
csua.org/u/7af -> www.perl.com/pub/a/2002/06/04/apo5.html?page=2
Advertisement O'Reilly Network. Safari Bookshelf. Conferences. Sign In/My Account | View Cart Articles Weblogs Books Learning Lab News O'Reilly Open Source Convention: July 26-30, Portland, OR. Open Source Wireless Bioinformatics Enterprise Development Atom Feed RSS Feed Related O'Reilly Books * Perl 6 & Parrot Essentials, 2nd Edition * Perl Debugger Pocket Reference * Perl CD Bookshelf, Version 40 * Perl Template Toolkit * Spidering Hacks * Mastering Perl for Bioinformatics * Regular Expression Pocket Reference * Perl Cookbook, 2nd Edition * Extreme Programming Pocket Guide * Perl 6 Essentials More Traveling to a tech show? Supported by: Car Insurance Life Insurance Print. Print Email. Email article link Apocalypse 5 by Larry Wall | Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 O'Reilly Open Source Convention -- July 22-26, San Diego, CA. From the Frontiers of Research to the Heart of the Enterprise Don't miss Larry Walls's presentation, Introducing The Perl 6 Language at the O'Reilly Open Source Convention in July. The conference includes many sessions and tutorials of interest to Perl developers. Regex culture has gone wrong in a variety of ways, but it's not my intent to assign blame--there's plenty of blame to go around, and plenty of things that have gone wrong that are nobody's fault in particular. For example, it's nobody's fault that you can't realistically complement a character set anymore. It's just an accident of the way Unicode defines combining characters. The whole notion of character classes is mutating, and that will have some bearing on the future of regular expression syntax. Given all this, I need to warn you that this Apocalypse is going to be somewhat radical. We'll be proposing changes to certain "sacred" features of regex culture, and this is guaranteed to result in future shock for some of our more conservative citizens. Do not be alarmed. We will provide ways for you to continue programming in old-fashioned regular expressions if you desire. But I hope that once you've thought about it a little and worked through some examples, you'll like most of the changes we're proposing here. So although the RFCs did contribute greatly to my thinking for this Apocalypse, I'm going to present my own vision first for where regex culture should go, and then analyze the RFCs with respect to that vision. First, let me enumerate some of the things that are wrong with current regex culture. Too much history * Too compact and "cute" * Poor Huffman coding * Too much reliance on too few metacharacters * Different things look too similar * Poor end-weight design * Too much reliance on modifiers * Too many special rules and boobytraps * Backreferences not useful enough * Too hard to match a literal string * Two-level interpretation is problematic * Too little abstraction * Little support for named captures * Difficult to use nested patterns * Little support for grammars * Inability to define variants * Poor integration with "real" language * Missing backtracking controls * Difficult to define assertions I'm sure there are other problems, but that'll do for starters. Let's look at each of these in more detail. Advertisement Contact Us | Advertise with Us | Privacy Policy | Press Center | Jobs | Submissions Guidelines Copyright 2000-2004 OReilly Media, Inc. All Rights Reserved. All trademarks and registered trademarks appearing on the O'Reilly Network are the property of their respective owners.