Hacker News Reader

Comment by brehaut | Hacker News Reader

I prefer fishbowl's law

   Every regexp that you apply to a particular block of text reduces 
   the applicability of regular expressions by an order of magnitude.

- http://fishbowl.pastiche.org/2003/08/18/beware_regular_expre...

The minimum any programmer needs to know about regexps is when they are applicable, and more importantly, when they are not.

View on HN

Seeing how im advocating that everyone should know when to be using parsing tools rather than cobbling together a regexp cludge, here are some links to some relevant tools in a variety of languages. Note that these are not parser generator tools, but parser combinator libraries:

    * Python: 
        PyParsing - http://pyparsing.wikispaces.com/ - this   
        is probably the most well respected parser library 
        for python 
        
        picoparse - http://github.com/brehaut/picoparse - My 
        parsec inspired parser combinator library. It is 
        significantly more light weight than pyparsing, and
        I would recommend pyparsing in its place for more 
        heavy lifting parsers.

    * Ruby:
        RParsec - http://rubyforge.org/projects/rparsec/ - A 
        ruby implementation of Parsec. I've heard good 
        things about it.

    * Haskell: 
        Parsec - http://legacy.cs.uu.nl/daan/parsec.html - 
        This is an amazing library, worth anyones time. 
        http://book.realworldhaskell.org/read/using-parsec.html 
        http://www.haskell.org/haskellwiki/Parsec

    * F#:
        FParsec - http://www.quanttec.com/fparsec/ - This is 
        reason enough to learn F#; it is a fairly true port 
        of the haskell library and very nice to use. 

    * Scala: 
        Packrat Parsing - I believe this is part of the 
        standard lib. http://www.scala-lang.org/docu/files/api/scala/util/parsing/combinator/PackratParsers.html 

    * Clojure: 
        fnparse - http://github.com/joshua-choi/fnparse

    * Java: 
        jparsec - http://jparsec.codehaus.org/

[edits: formating]

I think this actually illustrates the other guy's point. If you want a parser, you need to go download code off the internet. If you want a Regex, you type something along the lines of new Regex().

http://research.microsoft.com/en-us/um/people/daan/parsec.ht... "Nowadays, Parsec is distributed with the standard Haskell libraries with most Haskell compilers (GHC, NHC, Hugs)."

Treetop for Ruby looks pretty cool too: http://treetop.rubyforge.org/

Your link advocates writing parsers in situations where regexes aren't powerful enough, which is quite sensible and even quite practical in some cases.

But there's a big reason regexes are overused compared to parsers--regex engines come stock in most programming languages, and parser generators don't. There's a big mismatch in complexity between overusing something the language gives you for free and building in a parser. Perl 6 deserves some credit for their "rules" system, which can actually take a grammar and parse from it.

Agreed, the impedance of parsers has traditionally been much higher than for regexps. However, a lot of languages now have some sort of parse combinator library which dramatically increases the ease of writing a parser.

I'm thinking specifically of the Parsec inspired family, which has implementations or derivations in many common languages, even C# and Java (despite being noticably more cumbersome in those cases there).

[I cannot speak for perl 6, but i trust you are correct]

Reply on news.ycombinator.com