Regular Expressions – Mastering Lookahead and Lookbehind • Hacker News Board

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#81

Post by pygy_ » Sat, Mar 17, 2018, 8:01 AM UTC

OskarS wrote: post #29

Someone1234 wrote: post #15

Earlier quoted context omitted.

Which version of RegEx? I've "learned" RegEx two or three times and then switched language/platform and had everything I previously learned no longer work reliably. You might think I am just talking about Microsoft's quirky implementation but even in the Linux-sphere it isn't consistent see: http://www.greenend.org.uk/rjk/tech/regexp.html You take a complex format string which was design to use the fewest characters…

That's an overstatement of the differences between various regex engines. They all follow the basic standards, with [] being character classes, () being submatches, * being "0 or more", + being "1 or more", etc. The two main differences between various engines are which characters are "literal" and which characters are "magic" (Vim's engine is particularly annoying here), and how to write the "convenience character c…

That's the syntactic differences, but there are also semantic ones.

Most notably, the choice operator can either be ordered like in PEGs (if the first branch matches, the other isn't evaluated) or pick the branch that produces the longest match, CFG-like.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#82

Post by jokoon » Sun, Mar 18, 2018, 12:29 PM UTC

d--b wrote: post #41

> our pattern becomes: > \A(?=\w{6,10}\z)(?=[^a-z] [a-z])(?=(?:[^A-Z] [A-Z]){3})(?=\D \d). And then these guys wonder why people hate regexes? The "now you have 2 problems" quote fit perfectly for that case.

Can you put line returns and indents in a regex?

If you escape them it should work, I guess.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#83

Post by zombieprocesses » Sun, Mar 18, 2018, 2:14 PM UTC

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.

> I think they're great though, if you take the time to understand them.

Regular expression is useful for sure. What is terrible is that every language, shell and platform has different "styles and implementation". On windows, cmd, powershell, C#, sql server, etc all have their own styles. It's similar enough and at the same time different enough to drive you insane. Throw in linux with their shells, vi(m), perl, etc all using their own variants.

But the biggest problem is that regex is prone to "set it and forget it" issue. It's something we use once in a while and forget. Was it brackets or parentheses or braces for defining character ranges? Does . or + signify one or more? And ever try deciphering someone's undocumented multiline regex? Fun times.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#84

Post by zaarn » Mon, Mar 19, 2018, 7:32 AM UTC

_v7gu wrote: post #66

zaarn wrote: post #37

Earlier quoted context omitted.

Regex's are awesome as a swiss army knife. Though in my experience, outside some edge cases where the format never changes (like matching a domain name in a URL) a regex is hell to maintain when you come back 3 years later. There is also always the fun of people trying (and failing) to use regex in emails.

.+@.+ seems to be the only one without too many false-negatives

Well the best solution is to check if .+@(.+) matches and then try to lookup what the capture group returned via your DNS resolver. If it has an MX record (or CNAME to something with MX), then deliver the mail to there.

If you can't resole the domain part, return an error.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#85

Post by b2gills » Wed, Mar 21, 2018, 9:45 PM UTC

dash2 wrote: post #33

jstarfish wrote: post #5

Earlier quoted context omitted.

They're definitely useful, and I can cobble them together to get lots of otherwise tedious and complex parsing tasks done, but when I come back to them a week later I have no idea what the hell the pile of wingding vomit I wrote was supposed to do. I find myself writing simpler ones and tying them together with app code just for sanity's sake.

I wonder if Perl 6 regexes and grammars might show a way forward for more readable pattern matching.

An example would be helpful so here is one https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...