fparsec

How to parse comments with FParsec

有些话、适合烂在心里 提交于 2019-12-01 16:58:01
问题 I'm attempting to parse lisp-style comments from an s-expression language with FParsec. I got a bit of help with parsing single-line comments in this previous thread - How to convert an FParsec parser to parse whitespace While that was resolved, I still need to parse multiline comments. Here's the current code - /// Read whitespace character as a string. let spaceAsStr = anyOf whitespaceChars |>> fun chr -> string chr /// Read a line comment. let lineComment = pchar lineCommentChar >>.

How to parse comments with FParsec

為{幸葍}努か 提交于 2019-12-01 16:40:40
I'm attempting to parse lisp-style comments from an s-expression language with FParsec. I got a bit of help with parsing single-line comments in this previous thread - How to convert an FParsec parser to parse whitespace While that was resolved, I still need to parse multiline comments. Here's the current code - /// Read whitespace character as a string. let spaceAsStr = anyOf whitespaceChars |>> fun chr -> string chr /// Read a line comment. let lineComment = pchar lineCommentChar >>. restOfLine true /// Read a multiline comment. /// TODO: make multiline comments nest. let multilineComment =

FParsec identifiers vs keywords

可紊 提交于 2019-12-01 08:31:36
For languages with keywords, some special trickery needs to happen to prevent for example "if" from being interpreted as an identifier and "ifSomeVariableName" from becoming keyword "if" followed by identifier "SomeVariableName" in the token stream. For recursive descent and Lex/Yacc, I've simply taken the approach (as per helpful instruction) of transforming the token stream between the lexer and the parser. However, FParsec doesn't really seem do a separate lexer step, so I'm wondering what the best way to deal with this is. Speaking of, it seems like Haskell's Parsec supports a lexer layer,

FParsec identifiers vs keywords

大城市里の小女人 提交于 2019-12-01 05:36:03
问题 For languages with keywords, some special trickery needs to happen to prevent for example "if" from being interpreted as an identifier and "ifSomeVariableName" from becoming keyword "if" followed by identifier "SomeVariableName" in the token stream. For recursive descent and Lex/Yacc, I've simply taken the approach (as per helpful instruction) of transforming the token stream between the lexer and the parser. However, FParsec doesn't really seem do a separate lexer step, so I'm wondering what

How to add a condition that a parsed number must satisfy in FParsec?

荒凉一梦 提交于 2019-12-01 04:50:19
问题 I am trying to parse an int32 with FParsec but have an additional restriction that the number must be less than some maximum value. Is their a way to perform this without writing my own custom parser (as below) and/or is my custom parser (below) the appropriate way of achieving the requirements. I ask because most of the built-in library functions seem to revolve around a char satisfying certain predicates and not any other type. let pRow: Parser<int> = let error = messageError ("int parsed

Recursive grammars in FParsec

坚强是说给别人听的谎言 提交于 2019-11-30 07:20:22
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

Chunked Parsing with FParsec

Deadly 提交于 2019-11-28 04:29:49
问题 Is it possible to submit input to an FParsec parser in chunks, as from a socket? If not, is it possible to retrieve the current result and unparsed portion of an input stream so that I might accomplish this? I'm trying to run the chunks of input coming in from SocketAsyncEventArgs without buffering entire messages. Update The reason for noting the use of SocketAsyncEventArgs was to denote that sending data to a CharStream might result in asynchronous access to the underlying Stream .