Live data from Hacker News

I don't know Regex

ideasof.andersaberg.com

41–50 of 55 posts

Re: I don't know Regex

#41
post #16
post #10

I've been making good use of http://www.regexper.com/ since it was linked here. It's made learning regexes much easier as it gives a clear workflow diagram. For example, it showed that the horrible email regex in this article had a couple of errors - the dot before the TLD should be escaped (without the escape, it's 'any character'), and that group #1 can either be letters or digits, but not both (when it can be). It…

Personally I use http://www.debuggex.com/ since it offers a step by step visualization, a live generation of the diagram, a live syntax checking of the regex, etc.

Just playing around with it now, it's nice how it builds up the regex as you write it, but I did notice that it doesn't differentiate between '.' (match one character of any kind) and '\.' (the character for 'dot')

Hrm, on a closer look, it affects all special characters (like ^ and $) and it does differentiate them, but only by turning them blue - makes it hard to see the change.

Re: I don't know Regex

#42

I would like to point out that I am actually the creator of this idea, and not the author. The author has created a variation in C#, that has some differences. The original repository is at: https://github.com/thebinarysearchtree/RegExpBuilder I came up with this idea 2 years ago. Some differences I see between my idea and this c# implementation are: Or() is confusing by itself. In mine, you pass in objects or string…

You have my support! I read a blogpost showing off your RegExpBuilder and I got inspired to create something similiar (as a chance to improve my regex and coding skills)in C#, although I have some things I would love to do differently than how your lib does it.

Thank you for a great library, after I have reached stable with this C# port, i'd like to create a TypeScript version. I hope you do not have anything against me writing spinnofs? :)

Re: I don't know Regex

#43
With all respect, you're better off using a supportive regex environment that accepts your regex entries and quickly shows their effect on some example text you provide -- a builder/tester like this (just an example, there are many similar ones):

http://www.arachnoid.com/regex_lab/

Philosophically, there are two approaches to making regexes an effective tool -- expand regex syntax until it's so verbose that there's no possibility for confusion -- ironically a somewhat confusing tactic as this topic's comments demonstrate -- or learn native regex in an interactive way that shows its effect on example text, until you develop an instinct for it. I prefer the latter.

It's like learning music by keyboard -- shall we paint each keyboard key a different color and recode sheet music to agree, or shall we use a teaching method that makes the keyboard gradually seem more natural?

Re: I don't know Regex

#44

Your email regex is wrong. There are some obscure email address that will not work. For example my.email domain+plus@some.weird3.com For more see http://en.wikipedia.org/wiki/Email_address#Valid_email_addre...

I think that actually says a lot about regexes as code. The more corner cases you have to consider, the more unreadable the code gets, after a while by seemingly exponential degree. And if you have a tool to build the regex, why not just use the tool's code as your source so the final result is readable. Basically, pasting a big regex into your code hardly seems more desirable than pasting a bunch of assembler there.…

Email addresses are specified by standard with a context-free grammar. While it may be possible to express certain CF grammars as regular grammars, you rapidly run into issues (such as optional bounding delimiter matching, or escaped delimiters) which are trivial to express with a stack, and frickin' hard to express without one. (This is, incidentally, the heart of the "don't try to parse XML with regexp" sentiment, because XML is (at least) a context-free grammar that cannot be properly expressed by a regular grammar)

If you are having severe problems with a regex, the issue might be that you need to use an actual parser rather than a simple pattern matcher.

Re: I don't know Regex

#45

Which one is the simplest? I rest my case. Actually, I like neither. The code is easier to read, but the regex gives a broader overview. This is something where parser combinators can shine. E.g., from Haskell's email-validate: addrSpec = do localPart Source: http://hackage.haskell.org/packages/archive/email-validate/1... To end with a positive note: good work on the library! I think it will be useful for many people…

Just because it's a regex does not mean you can't document it. There are many regex tracers that can tell you exactly where a match fails. Plus regexes condense a lot of information in small spaces, which makes them easier (imho) to debug. Most other parsing syntaxes are one-offs, and very verbose.

And your average parsing library is not going to be using boyer-moore state machine parsing like you can easily achieve with regexes. It's complex, terse, fast, and the code that will be running your match is probably better debugged than any code you could hope to produce (it's most programmers' understanding of regexes that could use some debugging). Regexes also just make sense if you know the theory behind the state machines.

So how about this way of writing the regex :

  regex = r"""(?x)           # Extended syntax (ignores \n and whitespace, allows comments)
  # Regex to match email addresses
  \b                        # Word boundary
  (?P\w+)         # Username part
  @
  (?P[\w.]+)        # Domain
  \b                        # Word boundary
  """

  # Example use
  import re
  m = re.match(regex, "john@snow")

  print m.group('username')    # john
  print m.group('domain')      # snow
I find parser combinators very hard to use. I wrote parser combinator libraries in C and one in java thinking it'd be easier to use than a parser generator like ANTLR, and I've since rethought the process. ANTLR studio is just so useful for writing a parser to example data.

There's also the concern that parsers are strictly more expressive than regexes. If you need that, then regexes are simply out. However, most parser generators allow you to easily combine regex(-like) tokenization with parsing.

Re: I don't know Regex

#47
Some languages provide alternatives to Regexes. For eg. Rebol uses a parse dialect instead - http://www.rebol.com/docs/core23/rebolcore-15.html

Here is the articles example converted to Rebol's parse dialect (minus capturing but it's easy to add):

  ; build some prereqs for parse
  num:         charset [#"0" - #"9"]
  alpha-lower: charset [#"a" - #"z"]
  alpha-upper: charset [#"A" - #"Z"]
  alpha:       union alpha-lower alpha-upper
  alpha-num:   union alpha num 

  ; create parse rule block
  simple-email-rule: [
      alpha
      any alpha-num
      #"@"
      some alpha-num
      #"."
      some alpha-num
      end 
  ]

  ;
  ; then later...

  parse "valid@example.com" simple-email-rule  ; => true
  parse "notanemailaddress" simple-email-rule  ; => false

Re: I don't know Regex

#48
post #45

Which one is the simplest? I rest my case. Actually, I like neither. The code is easier to read, but the regex gives a broader overview. This is something where parser combinators can shine. E.g., from Haskell's email-validate: addrSpec = do localPart Source: http://hackage.haskell.org/packages/archive/email-validate/1... To end with a positive note: good work on the library! I think it will be useful for many people…

Just because it's a regex does not mean you can't document it. There are many regex tracers that can tell you exactly where a match fails. Plus regexes condense a lot of information in small spaces, which makes them easier (imho) to debug. Most other parsing syntaxes are one-offs, and very verbose. And your average parsing library is not going to be using boyer-moore state machine parsing like you can easily achieve…

Just because it's a regex does not mean you can't document it.

You are certainly right. Especially, if you use a package for automata or transducers that allows you to apply common automaton operations (union, intersection, composition, etc.) to combine expressions.

However, that's not how regular expressions are normally used or what the standard libraries for most languages support. So, people either write (1) simplified expressions (like yours above) that do not implement the relevant standard; (2) write unreadable expressions; (3) 'compose' expressions through string interpolation, which can become unreadable quite quickly (I've seen enough in production code).

I wrote parser combinator libraries in C and one in java thinking it'd be easier to use than a parser generator like ANTLR,

However yacc (which I assume you used for C) and ANTLR are hardly the state-of-the-art of parser combinators. Try parsec or attoparsec sometime.

There's also the concern that parsers are strictly more expressive than regexes.

Not only that, (sub-)parsers are fully typed, making it much easier and safer to combine parsers. E.g., here I know exactly what this parser will give me (namely a Bar):

  foo :: Parser Bar

Re: I don't know Regex

#49
post #4

His example could be simplified to ^ ( [a-z0-9]+ @ [a-z]+ \. [a-z]+ ) $ With ignore case and ignore whitespace mode on. I work with Regex a lot so I find this very readable, set in a universal format, and more concise. I will gladly concede that the builder would be easier for those that aren't familiar with regex.

I don't think it can - the local-part of the original matches as (a letter followed by letters) or (a letter followed by numbers): [A-Za-z]([A-Za-z]+|(?:\d+)) => [A-Za-z]([A-Za-z]+|\d+) Your version doesn't match this: - it allows numbers and digits to be interleaved - it allows the local-part to start with a digit [a-z0-9]+ != ([a-z]+|\d+)

You are right it should be ^ [a-z] [a-z0-9]* @ [a-z]+ \. [a-z]+ $ like someone else pointed out.

Re: I don't know Regex

#50
post #44

Earlier quoted context omitted.

I think that actually says a lot about regexes as code. The more corner cases you have to consider, the more unreadable the code gets, after a while by seemingly exponential degree. And if you have a tool to build the regex, why not just use the tool's code as your source so the final result is readable. Basically, pasting a big regex into your code hardly seems more desirable than pasting a bunch of assembler there.…

Email addresses are specified by standard with a context-free grammar. While it may be possible to express certain CF grammars as regular grammars, you rapidly run into issues (such as optional bounding delimiter matching, or escaped delimiters) which are trivial to express with a stack, and frickin' hard to express without one. (This is, incidentally, the heart of the "don't try to parse XML with regexp" sentiment,…

At that rate, I can't see any good reason to use regexes for email ever.

If you know context-free language, recursive-descent parsers are fairly simple to write and maintain without any special tools.

Post reply on HN