The problem here is that the `restOfLine` parser succeeds without consuming input if it is called at the end of the input (after the Test2 line). So `many restOfLine` would end up in an infinite loop if it didn't throw an exception. (The next version of FParsec will also state an input location in the exception message.)

There are several ways to workaround this issue if you really need to parse the complete input with a parser similar to `plines`. For example, `manyTill restOfLine eof` would do the trick. It's also easy to define a variant of `restOfLine` that doesn't succeed at the end of input (but does on empty lines):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
open FParsec.Primitives
open FParsec.CharParsers
open FParsec.Error


let pLine: Parser<_,_> =


    fun state ->


       let mutable str = null


       let newState = state.SkipRestOfLine(true, &str)


       if not (LanguagePrimitives.PhysicalEquality state newState) then


           Reply(str, newState)


       else


           Reply(Error, NoErrorMessages, newState)

With this parser definition in place you could simply define `plines` as `many pLine`.

This thread discusses code formatting on hubFS: [link:cs.hubfs.net]

By on 5/16/2010 1:24 AM ()

Thanks!

By on 5/16/2010 9:54 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper