parsec

I've decided to check out FParsec, and tried to write a parser for λ expressions. As it turns out, eagerness makes recursive parsing difficult. How can I solve this? Code: open FParsec type λExpr = | Variable of char | Application of λExpr * λExpr | Lambda of char * λExpr let rec FV = function | Variable v -> Set.singleton v | Application (f, x) -> FV f + FV x | Lambda (x, m) -> FV m - Set.singleton x let Λ0 = FV >> (=) Set.empty let apply f p = parse { let! v = p return f v } let λ e = let expr, exprR = createParserForwardedToRef() let var = lower |> apply Variable let app = tuple2 expr expr

I am going to write a parser of verilog (or vhdl) language and will do a lot of manipulations (sort of transformations) of the parsed data. I intend to parse really big files (full Verilog designs, as big as 10K lines) and I will ultimately support most of the Verilog. I don't mind typing but I don't want to rewrite any part of the code whenever I add support for some other rule. In Haskell, which library would you recommend? I know Haskell and have used Happy before (to play). I feel that there are possibilities in using Parsec for transforming the parsed string in the code (which is a great

Around 6 years ago, I benchmarked my own parser combinators in OCaml and found that they were ~5× slower than the parser generators on offer at the time. I recently revisited this subject and benchmarked Haskell's Parsec vs a simple hand-rolled precedence climbing parser written in F# and was surprised to find the F# to be 25× faster than the Haskell. Here's the Haskell code I used to read a large mathematical expression from file, parse and evaluate it: import Control.Applicative import Text.Parsec hiding ((<|>)) expr = chainl1 term ((+) <$ char '+' <|> (-) <$ char '-') term = chainl1 fact ((

Documentation for the parsec package states that u argument is used to carry some user state through monadic computation. But the same functionality can be achieved by basing ParsecT monad transformer on State monad. So if my parser is not stateful, i don't need u altogether, but have to set it to () with parsec. What's rationale for adding non-optional state support to ParsecT ? Because a parser of type ParsecT s () (State st) a behaves differently from a parser of type Parsec s st Identity a when it comes to backtracking: User state resets when parsec tries an alternative after a failing

The documentation for Parsec.Expr.buildExpressionParser says: Prefix and postfix operators of the same precedence can only occur once (i.e. --2 is not allowed if - is prefix negate). and indeed, this is biting me, since the language I am trying to parse allows arbitrary repetition of its prefix and postfix operators (think of a C expression like **a[1][2] ). So, why does Parsec make this restriction, and how can I work around it? I think I can move my prefix/postfix parsers down into the term parser since they have the highest precedence. i.e. **a + 1 is parsed as (*(*(a)))+(1) but what could

There seems to be a consensus that you should use Parsec as an applicative rather than a monad. What are the benefits of applicative parsing over monadic parsing? style performance abstraction Is monadic parsing out? The main difference between monadic and applicative parsing is in how sequential composition is handled. In the case of an applicative parser, we use (<*>) , whereas with a monad we use (>>=) . (<*>) :: Parser (a -> b) -> Parser a -> Parser b (>>=) :: Parser a -> (a -> Parser b) -> Parser b The monadic approach is more flexible, because it allows the grammar of the second part to

given the following type and function, meant to parse a field of a CSV field into a string: type Parser resultType = ParsecT String () Identity resultType cell :: Parser String I have implemented the following function: customCell :: String -> Parser res -> Parser res customCell typeName subparser = cell >>= either (const $ unexpected typeName) return . parse (subparser <* eof) "" Though I cannot stop thinking that I am not using the Monad concept as much as desired and that eventually there is a better way to merge the result of the inner with the outer parser, specially on what regards its