Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Regular Expressions – Mastering Lookahead and Lookbehind

rexegg.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#51

Post by bmn__ »

girvo wrote: post #14
paulryanrogers wrote: post #3

While useful to some I think advanced RE are like mixing in Perl or playing code golf with production code. They tend to make code harder to read. My preference in such cases is for multiple separated or longer REs (which can be at least split in the surrounding code) and each part named or heavily commented. Of course it's always worthwhile to consider non-RE solutions if the problem can be broken down enough. EDIT:…

I agree. Usually, I end up leaning on PEGs instead: https://nim-lang.org/docs/pegs.html

That's pretty bad:

    import pegs
    echo "xzxy" =~ peg"""
    B
Stack overflow

Nim needs to let go of its toy parsing algorithm.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#52

Post by pygy_ »

qaq wrote: post #48

for those who find regex not very readable: https://github.com/VerbalExpressions // Create an example of how to test for correctly formed URLs var tester = VerEx() .startOfLine() .then('http') .maybe('s') .then('://') .maybe('www.') .anythingBut(' ') .endOfLine();

https://github.com/pygy/compose-regexp.js is another option (800 bytes mingzipped):

    const {sequence, suffix} = composeRegexp;
    const maybe = suffix("?");
    const oneOrMore = suffix("+");

    const urlMatcher = sequence(
      /^/,
      "http"
      maybe("s"),
      "://",
      maybe("www."),
      oneOrMore(/[^ ]/),
      /$/
    );

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#53

Post by kbp »

swiley wrote: post #42
oftenwrong wrote: post #39

Earlier quoted context omitted.

regex engines like PCRE can: ^(\((?1)?\))$

If it can then it's not "regular expressions."

But when most of the commonly used "regular expression" libraries aren't regular, I think if you really mean solving something with only regular expressions, you should probably specify that explicitly. The term's been corrupted enough that using it by itself to rule out things like backreferences isn't clear communication.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#54

Post by loup-vaillant »

kbp wrote: post #53
swiley wrote: post #42

Earlier quoted context omitted.

If it can then it's not "regular expressions."

But when most of the commonly used "regular expression" libraries aren't regular, I think if you really mean solving something with only regular expressions, you should probably specify that explicitly. The term's been corrupted enough that using it by itself to rule out things like backreferences isn't clear communication.

That's a shame, because regular grammars have a very important property: they're processed with a Finite State Automaton. This makes them blazing fast and quite memory efficient. (Heck, even with a non-deterministic one they're fast.)

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#55

Post by GeoffKnauth »

Retra wrote: post #7
filipmandaric wrote: post #2

Most of the time I mention the topic of regular expressions to other developers, I usually hear self-critical commentary like "oh, I'm terrible at regex", and rarely anyone who loves them. I think they're great though, if you take the time to understand them. They're something like a Swiss Army knife for programming.

A programmer saying they are terrible at regex is like a mathematician saying they are terrible at algebra.

If I'm writing code that uses regexs, it helps me if I write at least 1 test case along with a helper function to make using the regex easier for me. E.g., I did the following in Scala recently. Shown is just one of many regexs I used to read SQLServer stored procedures and turn them into functions that would write the Scala code to use them.

  val inputIdTypWidthPat = new Regex("""(?si)@(\w+)\s+(\w+)\((\d+)\)""", "id", "typ", "width")

  val inputIdTypeWidthCheck = RxInputMatchGroups(inputIdTypWidthPat,
    List(InputMatchGroups("""@COUNTRY_CODE char(2),""",
      List(MatchGroups("""@COUNTRY_CODE char(2)""",
        List("COUNTRY_CODE", "char", "2"))))))

  def getIdTypWidth(s: String): (Option[(String, String, Int)], Int) = {
    val om: Option[Match] = inputIdTypWidthPat.findFirstMatchIn(s)
    if (om.isDefined) {
      if (om.get.groupCount == 3) {
        (Some(om.get.group(1), om.get.group(2), om.get.group(3).toInt), om.get.end)
      }  else (None, 0)
    } else (None, 0)
  }

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#56

Post by jessaustin »

wruza wrote: post #35
arthur5005 wrote: post #24

You’ve got a problem you think regex can solve, now you’ve got 2 problems.

I wrote a list of json keys that should be taken from a message and :‘ s/\(\S\+\)\s{0,}/t.\1 = message.\1;\r/g Hey, did you commit already? Still typing?

It looks like your quote characters might be messed up there? Anyway, to parse json on the command line one should just use jq.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#57

Post by lr4444lr »

amelius wrote: post #36
qiqitori wrote: post #8

Earlier quoted context omitted.

I think everyone who doesn't know regex should make learning regex a priority. (However, I find that lookahead and lookbehind in particular do not tend to come in handy very often. So maybe just make a mental note that this exists and then look it up when you need it.) Just learn the basics and maybe take a very quick look at the theory, finite automata (maybe the name puts people off, but its just a couple of circle…

But don't forget to point at the limitations. For example, you can't use regexps to match an arbitrary but equal number of nested opening and closing parentheses.

I presume you're familiar with the infamous "can you parse HTML with regex"?

https://stackoverflow.com/questions/1732348/regex-match-open...

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#58

Post by nolliebs180 »

> It is that at the end of a lookahead or a lookbehind, the regex engine hasn't moved on the string. You can chain three more lookaheads after the first, and the regex engine still won't move.

Omg, thank you, that is the insight I needed and now I completely get it. Internet +1 for the day.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#59

Post by JepZ »

sshine wrote: post #26

A use-case for lookarounds that I often use is: grep -Po '(? Which also cuts out and prints the relevant part of the line. This saves a trip through cut, awk or perl. (-P is PCRE and -o is print only matched characters, which the lookarounds aren't a part of.)

I like to add the lookahead:

  grep -oP '(?
The caveat however is that the look{ahead,behind} pattern has to be of fixed length.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#60

Post by amelius »

amelius wrote: post #36
qiqitori wrote: post #8

Earlier quoted context omitted.

I think everyone who doesn't know regex should make learning regex a priority. (However, I find that lookahead and lookbehind in particular do not tend to come in handy very often. So maybe just make a mental note that this exists and then look it up when you need it.) Just learn the basics and maybe take a very quick look at the theory, finite automata (maybe the name puts people off, but its just a couple of circle…

But don't forget to point at the limitations. For example, you can't use regexps to match an arbitrary but equal number of nested opening and closing parentheses.

Another potential problem with regexps is that the underlying finite state machine can grow exponentially in the size of the expression.
Post reply on HN