Re: Fast Haskell Parser

2010-03-11 Thread Thomas Schilling
quot;Thomas Schilling" > Sent: 11 Thursday March 2010 1026 > To: "John D. Earle" > Cc: "cvs-ghc" > Subject: Re: Fast Haskell Parser > >> You/we are talking about parser performance and parsing libraries in >> general, not about GHC development.  

Re: Fast Haskell Parser

2010-03-11 Thread Thomas Schilling
on > the GHC Developer Wiki? > > -- > From: "Ian Lynagh" > Sent: 11 Thursday March 2010 0850 > To: "John D. Earle" > Cc: "cvs-ghc" > Subject: Re: Fast Haskell Parser > >> >> Hi all

Re: Fast Haskell Parser

2010-03-11 Thread John D. Earle
How is it off topic? Am I not following the instructions that were given on the GHC Developer Wiki? -- From: "Ian Lynagh" Sent: 11 Thursday March 2010 0850 To: "John D. Earle" Cc: "cvs-ghc" Subject: Re: Fast H

Re: Fast Haskell Parser

2010-03-11 Thread Ian Lynagh
Hi all, This discussion is off-topic here. Can you please take it to the haskell-cafe list? Thanks Ian ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Re: Fast Haskell Parser

2010-03-11 Thread John D. Earle
lling" Sent: 11 Thursday March 2010 0748 To: "John D. Earle" Cc: "cvs-ghc" Subject: Re: Fast Haskell Parser No, it's not lazy vs. strict. Parsec's "try" switches the default LL(1) parser to an LL(N) parser. Happy is always LALR(1), which is some

Re: Fast Haskell Parser

2010-03-11 Thread Thomas Schilling
No, it's not lazy vs. strict. Parsec's "try" switches the default LL(1) parser to an LL(N) parser. Happy is always LALR(1), which is somewhere in the middle. ReadP is always LL(N) but is efficient by using a breadth-first search instead of depth-first search. The efficiency of ReadP depends on

Re: Fast Haskell Parser

2010-03-11 Thread John D. Earle
Simon Marlow: Personally I find Parsec and the other parser combinator libraries quite difficult to use when it comes to deciding where to put 'try'; ReadP is the exception here, because it does general backtracking and doesn't make you decide where to use 'try'. John D. Earle: I bet this has

Re: Fast Haskell Parser

2010-03-11 Thread John D. Earle
. -- From: "Simon Marlow" Sent: 11 Thursday March 2010 0328 To: "John D. Earle" Cc: "cvs-ghc" Subject: Re: Fast Haskell Parser On 11/03/2010 01:25, John D. Earle wrote: Hi, Ben! Thanks for the input. I went to the Parsec and Attoparsec parser links. Atto

Re: Fast Haskell Parser

2010-03-11 Thread Simon Marlow
Thank you this has helped clarify my thinking. -- From: "Ben Lippmeier" Sent: 10 Wednesday March 2010 1734 To: "John D. Earle" Cc: Subject: Re: Fast Haskell Parser Hi John, Doing a Google search for "haskell parser" r

Re: Fast Haskell Parser

2010-03-10 Thread John D. Earle
k you this has helped clarify my thinking. -- From: "Ben Lippmeier" Sent: 10 Wednesday March 2010 1734 To: "John D. Earle" Cc: Subject: Re: Fast Haskell Parser Hi John, Doing a Google search for "haskell parser"

Re: Fast Haskell Parser

2010-03-10 Thread Ben Lippmeier
Hi John, Doing a Google search for "haskell parser" returns the following link as its first result. That's the parser that GHC uses. http://www.haskell.org/happy/ You could also check out the following: http://www.haskell.org/haskellwiki/Parsec http://hackage.haskell.org/package/attoparsec

Fast Haskell Parser

2010-03-10 Thread John D. Earle
I was thinking of ways to create an efficient Haskell parser. My initial thinking was to write a top down parser in Haskell, but if you want speed a table driven approach may make greater sense. Due to the existence of build bots there is a certain degree of compliancy concerning build times.