in reply to Simple regex question

Without using advanced regexp stuff:
s/(\s\?|\?\s)|\?/$1 || "'"/eg; # Look ma, no look behind/ahead
But that may replace a question mark at the end of a string (or beginning). If you don't want that:
1 while s/(\S)\?(\S)/$1'$2/;
I am assuming that with "space", you mean any whitespace. If you really mean just a space (and not tabs, newlines, etc), replace \s with a space, and \S with [^ ].

Replies are listed 'Best First'.
Re^2: Simple regex question
by AnomalousMonk (Archbishop) on Sep 15, 2010 at 18:24 UTC

    I haven't checked, but look-around assertions have certainly been around for many years, perhaps more than a decade. Can they really still be considered to be 'advanced'?

    Also, the  (?<!\?) and  (?!\?) assertions seem to me to perfectly express the notions 'not preceded by...' and 'not followed by...', respectively. Are they not preferable to the somewhat convoluted logic of your example code? (Admitedly, this may be largely a matter of taste.)

      I haven't checked, but look-around assertions have certainly been around for many years, perhaps more than a decade. Can they really still be considered to be 'advanced'?
      How long a construct has been part of a language doesn't determine whether it's advanced or not. They are described in the section:
         Extended Patterns
             Perl also defines a consistent extension syntax for features not found
             in standard tools like awk and lex.  The syntax is a pair of
             parentheses with a question mark as the first thing within the
             parentheses.  The character after the question mark indicates the
             extension.
      
             The stability of these extensions varies widely.  Some have been part
             of the core language for many years.  Others are experimental and may
             change without warning or be completely removed.  Check the
             documentation on an individual feature to verify its current status.
      
             A question mark was chosen for this and for the minimal-matching
             construct because 1) question marks are rare in older regular
             expressions, and 2) whenever you see one, you should stop and
             "question" exactly what is going on.  That’s psychology...
      
      I can very well imagine that some people call this an advanced structure.
      Also, the (?<!\?) and (?!\?) assertions seem to me to perfectly express the notions 'not preceded by...' and 'not followed by...', respectively.
      That's fine. And if the OP is fine with that, he'll use it. If he doesn't like it (or anyone else who stumbles upon this thread), I've offered him an alternative.

      There's more than one way to skin a cat.

        We may be running afoul of differing or overlapping definitions of the meanings of words like 'advanced' and 'extended'. If 'advanced' is more or less synonomous with 'extended', then look-arounds are, as described in the quoted section of perlre, advanced anent awk- and lex-ish usage.

        I think 'advanced', in this context, has more to do with words like 'complicated', 'subtle', 'non-intuitive' or 'counter-intuitive'. To me, look-arounds are pretty straightforward and intuitive (except for the fixed-width limitation of look-behinds), thus not advanced at all. I also think that look-arounds fall squarely under the 'part of the core language for many years' rubric of the quoted perlre section, and are not likely to change their behavior for the future of Perl 5.

        Given that look-arounds are mature, stable and straightforward, it is well to commend regex tyros (as ultranerds seems to be) to their familiarity and use. Alternatives and multiple cat-skinning methods are fine (and I agree that the OPer is the final arbiter), but they should not obscure expressive and stable features of the language from which newcomers may benefit.

        My personal experience is that pretty much all regex behavior is one or more of complicated, subtle, and non- or counter-intuitive (and that applies to the approach taken in your example code), so no expressive, stable extension should ever be shunned.