3 ms·

How do these improve regular expressions?

• tantalor 10y ago
  It doesn't improve regexp; it improves your code that uses regexp to populate type-checked data. Instead of writing a lot of "if foo is int then ..." type checking code you can just annotate the regexp with types and it either extracts those types for you or throws an error or something. In general you have the same problem when parsing CSV, command line flags, URL query parameters, JSON, etc.
  • Kinnard 10y ago
    I see! Thanks.
  • willvarfar 10y ago
    Those type-safety problems for parsing tainted data are a royal pain and, often, security issues! Typed regex are a very good idea and very welcome. At the moment, when I use regex and extraction, I have a lot of boilerplate and I could easily have lots of bugs unfuzzed. (For those having the type-safety problem with JSON in Python, can I recommend my own library obiwan? https://pypi.python.org/pypi/obiwan/ https://pypi.python.org/pypi/obiwan/ :) )
  • chongli 10y ago
    At this point, why not just use the more powerful, maintainable, and flexible parser combinators[0]? I thought the point of regex was for quick and dirty bash/grep/perl one-liners and search/replace in vi/emacs. If you're going to actually maintain the code, then use something designed for that. [0] https://en.wikipedia.org/wiki/Parser_combinator https://en.wikipedia.org/wiki/Parser_combinator
    • Drup 10y ago
      Well, there is the speed argument. Regular expressions (not the pcre kind with backtracking and stuff) are blazing fast. Ragel[1] is a good example of that. In general, though, I actually agree. [1]: http://www.colm.net/open-source/ragel/ http://www.colm.net/open-source/ragel/
      • chongli 10y ago
        Among parser combinator libraries, attoparsec[0] is no slouch. It gets very close to the speed of the hand-rolled http-parser library while being much shorter, easier to read, and maintain[1]. [0] https://hackage.haskell.org/package/attoparsec https://hackage.haskell.org/package/attoparsec [1] http://www.serpentine.com/blog/2010/03/03/whats-in-a-parser-attoparsec-rewired-2/ http://www.serpentine.com/blog/2010/03/03/whats-in-a-parser-...
      • tantalor 10y ago
        Another good example is RE2: https://github.com/google/re2 https://github.com/google/re2 It's pretty fast too. I don't know whether you can compare the performance of Ragel to regex libraries like RE2; they look like they solve different problems.
      • gergoerdi 10y ago
        As I mentioned in another comment, there are applicative parser combinator libraries for regular languages, e.g. https://hackage.haskell.org/package/regex-applicative https://hackage.haskell.org/package/regex-applicative so asymptotic speed is orthogonal to 'combinatorialness'.
        • Drup 10y ago
          If you look at the API of ocaml-re (and tyre), you'll see it's pretty much equivalent to regex-applicative. Regex combinators are nice. "Parser combinators", for me, denotes actual parsers, for non-contextual or contextual grammars.
    • tantalor 10y ago
      Consider the regex may be program input, so you can't just code them away. A search engine is a good example.
  • Drup 10y ago
    Indeed, that is the exact goal. For the little history, I started this for URLs[1]. I couldn't (and still can't) figure out a proper interface for that, but someone mentioned he would like something like that for regular expressions, so here it is. We already have something similar for command line flags in OCaml[2] (and several for JSON). [1]: https://github.com/Drup/furl https://github.com/Drup/furl [2]: http://erratique.ch/software/cmdliner http://erratique.ch/software/cmdliner