Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
On 3 Aug 2013, at 02:20, Jason Dagit wrote: >> Hi! >> Is there any specific reason why GHC is written in a parser GENERATOR >> (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? >> >> Is Happy faster / handles better errors / hase some great features or >> anything else? > > One reason is that it predates monadic parser libraries. I'm not entirely sure this is true. I reckon the development of applicative parser combinators (used in the implementation of the nhc12 compiler, way back in 1995 or so), is roughly contemporaneous with the development of Happy, and its use inside ghc. (I found a release note from Sept 1997 that said ghc had just converted its interface-file parser to use Happy.) Certainly table-driven parsers in non-functional languages go back a lot further, and functional combinator-based parsing was then the relative newcomer. As to why ghc switched to Happy, the literature of the time suggests that generated table-driven parsers were faster than combinator-based parsers. I'm not sure I have ever seen any performance figures to back that up however. And with the general improvement in performance of idiomatic Haskell over the last twenty years, I'd be interested to see a modern comparison. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Spam on the Haskell wiki
Anyone ran SpamAssassin on the offending content created by the spammers? I've been using it on hpaste and it's been very effective at cutting out the crap. On 4 August 2012 19:15, Gwern Branwen wrote: > On Fri, Aug 3, 2012 at 10:34 PM, damodar kulkarni > wrote: > > So, another doubt, if detecting spam is trivial, then why not just send > the > > detected spam to trash directly without any human inspection? > > This may mean some trouble for the posters due to "false positives"; but > the > > moderator's job can be reduced to some extent. > > Which is pretty much what this whole thread is about: asking that the > sysadmins Do Something about this trivial yet overwhelming spam. > > -- > gwern > http://www.gwern.net > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
On Sat, Aug 3, 2013 at 3:36 AM, Malcolm Wallace wrote: > > On 3 Aug 2013, at 02:20, Jason Dagit wrote: > >>> Hi! >>> Is there any specific reason why GHC is written in a parser GENERATOR >>> (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? >>> >>> Is Happy faster / handles better errors / hase some great features or >>> anything else? >> >> One reason is that it predates monadic parser libraries. > > I'm not entirely sure this is true. I reckon the development of applicative > parser combinators (used in the implementation of the nhc12 compiler, way > back in 1995 or so), is roughly contemporaneous with the development of > Happy, and its use inside ghc. (I found a release note from Sept 1997 that > said ghc had just converted its interface-file parser to use Happy.) > Certainly table-driven parsers in non-functional languages go back a lot > further, and functional combinator-based parsing was then the relative > newcomer. Interesting. I know the happy source has copyright dates starting in 1991, so I figured it was developed to help write ghc. Perhaps they were using it for source parsing before they adopted it for interface-file parsing in 1997? > As to why ghc switched to Happy, the literature of the time suggests that > generated table-driven parsers were faster than combinator-based parsers. > I'm not sure I have ever seen any performance figures to back that up > however. And with the general improvement in performance of idiomatic > Haskell over the last twenty years, I'd be interested to see a modern > comparison. Another con of using parsec that I forgot to mention in my previous email is that with Parsec you need to be explicit about backtracking (use of try). Reasoning about the correct places to put try is not always easy and parsec doesn't help you with the task. In my experience, this is the main bug that people run into when using parsec. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
