I like how the FParsec docs are written and was wondering how I might author something similar, but I don't see how the docs are built in the repo. Is it a well known format that need only be processed by some simple tool? I just don't recognize it.

While trying to write my own implementation of a parser for numbers with underscores between digits, I found I wanted a stringsSepBy1 function. I want to define a numbers-with-underscores parser that would look something like this:

let digitSequence = stringsSepBy1 (manySatisfy isDigit) (pchar '_' >>% "")
let numberWithOptionalSign =
    opt (pchar '+' <|> pchar '-') .>>.? digitSequence
    |>> (fun signOpt digits ->
        let sign = defaultArg signOpt '+'
        Int32.Parse digits * if sign = '-' then -1 else +1)

This would also allow me to reuse the digitSequence parser in a float parser later on.

But if I only have stringsSepBy and not stringsSepBy1 available, then the digitSequence parser could succeed with no digits matched, which would mean that the .>>.? combinator would not back up, and the entire numberWithOptionalSign parser could match against "+", or "-", or even the empty string, and so my (char option * string) -> int function isn't actually safe. If I can use stringsSepBy1, though, then the parser can only match against "+1" but not against "+", and my int-producing function is safe. (Except for overflow, but I'll skip that for simplicity's sake).

It should be pretty straightforward to implement a stringsSepBy1 function, I think.

'\uFFFF' is FParsec's special end-of-stream character (EOS). Unfortunately, there are some files in the wild that actually contain this character, and anyChar will fail when it encounters it:

let str = string EOS
let result = runParserOnString anyChar () "" str
printfn "%A" result

Output:

Failure:
Error in Ln: 1 Col: 2
�
 ^
Note: The error occurred at the end of the input stream.
Expecting: any char

Firstly: thanks for a creating this nice library!

When running a WindowsStore (Windows 8.1) project in Xamarin Forms there is the following runtime exception when trying to access the code written with FParsec:

"System.TypeInitializationException: The type initializer for '<StartupCode$MathsAppXF>.$parseAns' threw an exception. ---> System.TypeAccessException: Attempt by security transparent method 'FParsec.CharParsers.pchar(Char)' to access security critical type 'Microsoft.FSharp.Core.FSharpFunc2<FParsec.CharStream1<u>,FParsec.Reply1<System.Char>>' failed.\r\n at FParsec.CharParsers.pchar[u](Char c)\r\n at <StartupCode$MathsAppXF>.$parseAns..cctor()\r\n --- End of inner exception stack trace ---\r\n at parseAn" string`

We are using Xamarin Forms with Profile 111. We have also tried changing the TargetFrameworkProfile in the fsproj to Profile259 and got the same behaviour. The PCL is written in FSharp and the platform specific code in CSharp. We are using FParsec in the PCL and everything works very well for UWP and iOS projects.

Can FParsec be made to work for the WindowStore project also?

Hey, thanks for making this awesome lib. I'm getting the following issue:
I created a classlib using dotnet new and installed a reference to FParsec using paket. I then made a separate console application which references this classlib. When doing this, I get an Assembly version mismatch error which causes the console app to crash on start

Repro steps below:

1. dotnet new console -n wwh-cli -lang f#
2. dotnet new classlib -n wwh-parse -lang f#
3. dotnet new sln -n WWH
4. Copy .paket into directory
5. paket.exe init
6. Create paket.references in wwh-parse classlib with FParsec reference
7. paket.exe add FParsec --version 1.0.3
8. Ionide - Add wwh-cli project to sln
9. Ionide - Add wwh-parse project to sln
10. Ionide - Add wwh-parse project reference to wwh-cli console app
11. Dotnet run -- run console app and get the following errors

WWH\wwh-cli\wwh-cli.fsproj : warning NU1605: Detected package downgrade: FSharp.Core from 4.3.4 to 4.2.3. Reference the package directly from the project to select a different version.
WWH\wwh-cli\wwh-cli.fsproj : warning NU1605:  wwh-cli -> wwh-parse -> FSharp.Core (>= 4.3.4)
WWH\wwh-cli\wwh-cli.fsproj : warning NU1605:  wwh-cli -> FSharp.Core (>= 4.2.0)
WWH\wwh-cli\wwh-cli.fsproj : warning NU1605: Detected package downgrade: FSharp.Core from 4.3.4 to 4.2.3. Reference the package directly from the project to select a different version.
WWH\wwh-cli\wwh-cli.fsproj : warning NU1605:  wwh-cli -> wwh-parse -> FSharp.Core (>= 4.3.4)
WWH\wwh-cli\wwh-cli.fsproj : warning NU1605:  wwh-cli -> FSharp.Core (>= 4.2.0)
C:\Program Files\dotnet\sdk\2.1.4\Microsoft.Common.CurrentVersion.targets(2041,5): warning MSB3277: Found conflicts between different versions of "FSharp.Core" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed.
[WWH\wwh-cli\wwh-cli.fsproj]

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'FSharp.Core, Version=4.4.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at Program.main(String[] argv)

What it should do

It should run the console app

Workarounds

If I add a reference in the console app to FParsec in paket.references file, the error goes away

Thanks for your help!

As it's already a PCL package it should be a small step to just target netstandard. This saves netstandard/netcore dependees of having to specify this in their proj file:

    <PackageTargetFallback>portable-net45+win8+wp8+wpa81</PackageTargetFallback>

Since a parser combinator is a monad, I wonder if it's possible to create a new computation expression parser, then we could make our parser much elegant

let assignExpr = parser {
    let! identifier = some expr
    spaces >>. pstring "=" >>. spaces
    let! expr = some expr
    pstring ";"
    return (identifier, expr)
}

As stated in this SO question, is there a way to accomplish this without having to manually write an OPP? Maybe the Operator class could be modified to accept a 'a -> 'a -> Parser<'a,'u>, so that errors can be generated there...

Is it possible to add an implicit operator to an OperatorPrecenceParser? For instance, could the OOP sample be extended such that the test case calculate "(1+1)(2+2)" |> equals 8. (implicit multiplication) does not fail?

As far as I can see the OOP type does not support this. In case that's true: would you consider this feature a worthwhile extension of the type?

Sorry to be a bother, but could you take a look at the question I posted on SO and tell me if extending the precedence parser with a before parse check would be viable? I'd like to place that as a feature request.

I also think that from a design perspective that instead of setting the term parser on a property, it would have been better to pass it as an argument into the expression parser. Right now I could probably hack the after string parser in the individual operators to perform the indentation check, but it would be better the check happens before the operator parser gets triggered.

Now that Java and F# allow underscores in numeric literals, and some configuration file syntaxes like TOML do as well, it would be nice if the numberLiteral parser had an optional flag for allowing underscores between digits. As it is, if I want to write a TOML parser, I won't be able to leverage numberLiteral and I'll have to essentially reimplement it myself.

This has been reported here on StackOverflow, and here for F#.

Bottom line is that FParsec is not up-to-date with the more recent versions of FSharp.Core and a bug related to FSharpFunc lead to the latter raising MissingMethodException, even when the method is actually available. Using bindingRedirect does not solve the issue.

If your project uses FSharp.Core 4.3.4 or later you can run into this issue, however it doesn't always throw. It is difficult to create a minimal repro, but the resolution is simple: compile FParsec against a newer version of FSharp.Core and it works.

I propose that new binaries be created for the NuGet downloads and that the project be updated to use a new(er) version of FSharp.Core from NuGet, as this will solve this hard to trace error. It wouldn't be a bad thing to do since the last version is from 2017.

The actual error I see is the following, but the actual error one sees can be of a different generic instantiation:

----> System.MissingMethodException : Method not found: 'Microsoft.FSharp.Core.FSharpFunc`2<FParsec.CharStream`1<!!1>,FParsec.Reply`1<!!0>> FParsec.Primitives.op_DotGreaterGreater(Microsoft.FSharp.Core.FSharpFunc`2<FParsec.CharStream`1<!!1>,FParsec.Reply`1<!!0>>, Microsoft.FSharp.Core.FSharpFunc`2<FParsec.CharStream`1<!!1>,FParsec.Reply`1<!!2>>)'.

I got the FParsec source from Github yesterday and tried to open the solutions in Visual Studio 2017. I had previously installed the update to VS 2017 that came out yesterday, version 15.5 Preview 4. I have both the .NET Desktop and .NET Core workflows installed.

I can open and build the "legacy" FParsec.sln in the /Build/VS11 folder. But when I try to open the "master" FParsec.sln in the root folder, VS 2017 fails to load the FParsec, FParsecCS, and Test projects. In each case the output windows says:

Could not load file or assembly 'NuGet.VisualStudio.Implementation, Version=4.4.0.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The FParsec documentation says "The solution file in the root source folder does not yet properly work within the Visual Studio 2017 IDE (due to incomplete support for F# in VS). However, the folder Build/VS11 contains a solution file that works with Visual Studio 2012 and later."

Microsoft announced yesterday that with the latest updates, VS 2017 supports F# in .NET Core and .NET Standard projects. https://blogs.msdn.microsoft.com/dotnet/2017/11/15/announcing-f-support-for-net-core-and-net-standard-projects-in-visual-studio/

So I'm wondering if it's possible for me to fix this error now, or if the FParsec contributors have a timeline for resolving this.

Is there some limitation to how big a file FParsec supports? What I could find out from the code is that it reads by chunks, but I cannot seem to find which StringBuilder.Append is failing.

System.ArgumentOutOfRangeException: The length cannot be greater than the capacity. (Parameter 'valueCount')
   at System.Text.StringBuilder.Append(Char* value, Int32 valueCount)
   at System.Text.StringBuilder.Append(Char[] value, Int32 startIndex, Int32 charCount)
   at FParsec.CharStream.StreamConstructorContinue(Stream stream, Boolean leaveOpen, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 byteBufferLength)
   at FParsec.CharStream..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 byteBufferLength)
   at FParsec.CharStream..ctor(String path, Encoding encoding)
   at FParsec.CharStream`1..ctor(String path, Encoding encoding)
   at FParsec.CharParsers.runParserOnFile[a,u](FSharpFunc`2 parser, u ustate, String path, Encoding encoding)

File.ReadAllText on the same file throws System.OutOfMemoryException: Insufficient memory to continue the execution of the program. so I have to parse it in chunks.

Since I have some free time right now, I've been trying to test out the digit-separator branch as requested in #2 (comment), but I only have a Linux development machine, so PowerShell build scripts aren't all that easy for me to use. Result: the Windows-only build process for FParsec is currently blocking me from making any progress on helping with #2.

Would you be interested in a cross-platform build process, using Paket and FAKE instead of NuGet and PowerShell? I can't guarantee that I'd have time to work on it anytime soon, but I would be willing to put in the work if you'd find it useful — and if I can find the time (always the biggest limiting factor for me). I just don't want to invest the time in making a cross-platform build process if you wouldn't find that useful.

I tried to get FParsec from Nuget, but it failed. I will be happy when it becomes available.

NuGet Error NU1108
A circular dependency was detected.
The package is authored incorrectly; contact the package owner to correct the bug.

Excuse me, I'm not used to English and GitHub.

I've just started out with FParsec, and I'm not super well versed in F#.

I found that doing

#r "./FParsec.dll"
#r "./FParsecCS.dll"

open FParsec

let asStr s = pstring s

let numberBetweenQuotes = 
  asStr "\"" >>. pfloat .>> asStr "\""

printfn "%A" (run numberBetweenQuotes "\"100,200.00\"") |> ignore

This throws an error:

error FS0074: The type referenced through 'FParsec.CharStream`1' is defined in an assembly that is not referenced. You must add a reference to assembly 'FParsecCS'.

However, if you switch the order of the #r then it goes away:

#r "./FParsecCS.dll"
#r "./FParsec.dll"

Is this a known caveat - following the tutorial, it doesn't say anything about that. And it just so happens by chance that I tried it out.

Is this an fparsec thing or a f# script thing - or a combination of the both? Is it worth documenting?

Hello,
I've found a curious case, which I don't know how to solve. I wonder if I'm missing some obvious solution.

Let's say that I have a type

type UserState =
  { Sub1: Substate1
    Sub2: Substate2 }

And I have a parser of type

let parseWithSub1 : Parser<'a,Substate1> =
  // Implementation...

Is there a posibility to map this state, so that I can use it like

let parseWithUserState : Parser<'a,UserState> =
  mapUserState (fun x -> x.Sub1) parseWithSub

where mapUserState would be a hypothetical function of signature ('u1 -> 'u2) -> Parser<'a,'u1> -> Parser<'a,'u2>?

Pattern matching on characters is great, but seems unnecessarily restrictive. Being able to "parse" streams of any given type would seem to be a powerful tool.

I don't know if this is the right place to talk about it, but I think there is a word missing here.

http://www.quanttec.com/fparsec/reference/operatorprecedenceparser.html#members.Precedence

Shouldn't it be: The value is always greater than zero. instead of: The value is always greater zero.

The signed net45 pinned to assembly version 1.0.0.0 and unsigned netstandard2.0 with running versions (currently 1.1.1.0) is causing all sorts of issues. net45 is dead, could we please remove it and just have the netstandard2.0 assembly in there?

Add sourcelink

ref https://github.com/dotnet/sourcelink

Is there any reason the core is written in C#?

Would there be any appetite for a pure F# port?

Recently, I tried to use FParsec for a project in netcoreapp1.1. While it worked on netcoreapp1.0 using "portable-net45+win8+dnxcore50", the latest netcoreapp doesn't support this.

So, will you support dotnetcore?

We have an embedded plugin that builds on top of FParsec 1.0.2 from NuGet, which is built against FSharp.Core 4.3.0.0.
Due to bugfix upgrades in other F# libraries, we're forced to update to FSharp.Core 4.4.0.0, using this NuGet package https://www.nuget.org/packages/FSharp.Core/4.0.0.1

The use of FSharp.Core 4.4.0.0 causes errors at runtime since FParsec always expects FSharp.Core 4.3.0.0. If we have controls of main programs, adding FSharp.Core binding redirects to the main app.config would solve the mismatches. However, in the way our plugin is used, we don't have access to the main entry points. Moreover, by design, .NET applications ignore app.config of their libraries.

I see that there is a newer alpha at https://www.nuget.org/packages/FParsec/1.0.3-alpha-170404, but we're not in the position to use FSharp.Core 4.4.1.0 and .NET standards yet.

I know it sounds like a minor use case, but could you please publish a NuGet package version that is compatible with FSharp.Core 4.4.0.0/VS 2015? Similar issues with explanations could be found at dotnet/fsharp#789 (comment).

Thank you.

This issue probably isn't FParsec's fault per se, but it's something that FParsec will probably need to work around since I doubt the root cause of the issue will be fixed.

When building FParsec on Linux with Mono, I ran into several issues, one of which is the following exception thrown when running test_fparsec.exe after the build has completed:

System.Runtime.Serialization.SerializationException: The type 'I18N.CJK.CP932Decoder' is not marked as serializable.
  at FParsec.Cloning.Cloner.CreateWithoutLock (System.Type type) [0x0002e] in <e6b426514886430789b41741320a466a>:0 
  at FParsec.Cloning.Cloner.Create (System.Type type) [0x00010] in <e6b426514886430789b41741320a466a>:0 
  at FParsec.Test.CloningTests.encodingTests () [0x0007c] in <5a3691c4f61b05e0a7450383c491365a>:0 
  at FParsec.Test.CloningTests.run () [0x00037] in <5a3691c4f61b05e0a7450383c491365a>:0 
  at AllTests.run () [0x000bc] in <5a3691c4f61b05e0a7450383c491365a>:0 
  at <StartupCode$test_fparsec>.$AllTests.main@ () [0x00001] in <5a3691c4f61b05e0a7450383c491365a>:0 

Looking at the Mono source, it seems that the error message is 100% correct: CP932Decoder is not serializable. I haven't been able to find any documentation that specifies that decoder instances are supposed to be serializable, so I doubt the Mono project will consider it a bug that the CP932Decoder class (and many other decoders) do not have the Serializable attribute. Therefore, FParsec will probably need to work around this issue.

I worked around this by wrapping a try ... with :? System.Runtime.Serialization.SerializationException -> () expression around the tests in question (inside the for loop). That worked for me. And I don't know if there's much value in testing old single-byte codepages whose Mono code hasn't been touched since 2006, so I think that the simplistic solution (just skip the test if a SerializationException happens) is probably best here.

Would it be possible to extend FParsec with support for non UTF16 data?

That was FParsec could be used for parsing HTTP requests and other binary formats, even if the actual destructuring of the binary data would be left to the caller.

Do you have any plans to create git-book from this tutorial?

It appears that FParsec prints exceptions to the console (stdout). Is there a way to disable this behavior?

code -
run (many hex) "AB1C12xy1z1Ax2xA3"
run (many hex) "AB12A1B"
run (many hex) "xy12x1y"
run (many hex) "ABxyAxB"
run (many hex) "xyz"

output -
Success: ['A'; 'B'; '1'; 'C'; '1'; '2']
Success: ['A'; 'B'; '1'; '2'; 'A'; '1'; 'B']
Success: []
Success: ['A'; 'B']
Success: []

Issue - the hex parser isn't working for some combinations of 'A' - 'Z' , 'a' - 'z' and '0' - '9'. It isn't working for smaller case letters as well.

Would it be possible to have a release for net5.0?
Thanks for the great library!

The ErrorMessage.ExpectedString String property getter reads from itself instead of the base class String property. This causes a stack overflow when accessing it.

It looks to me that the same goes for ErrorMessage.UnexpectedString and ErrorMessage.Message.

The documents warn us that using computation expressions will be slower than we might expect.

The upcoming release of F#5 is adding support for applicatives in computation expressions. Will this slowness still be an issue if we use the new applicative syntax, provided FParsec provides support for it?

The docs says unicodeSpaces skips over *one* or more unicode spaces, but it actually skips over *zero* or more. Probably copied from unicodeSpaces1.

I'm working on a TOML parser, and I'm a bit at a loss for how to parse unicode characters that have surrogates in UTF-16/UCS-2 (I mention TOML because these codepoints are valid in it). I'm not deeply familiar with the CharStream in FParsec, but at a first reading it doesn't seem to have any notion of surrogates, and deals entirely with sequences of individual characters of type char.

Is there a way to parse surrogate pairs?

Might be good for perf to have a version of .>>. that returns a struct tuple

The 1.1.0+ versions are no longer getting signed and they are getting flagged by Windows with unknown publisher. I can't actually update to the latest version with this issue due to highly sensitive security checks on my side.

Support for netstandard1.6 causes assembly binding trouble, at least when support for netstandard2.0 would be preferred.

Steps to reproduce

Suppose you have two F# (or C#) projects, namely a library libfoo and an application appbar. libfoo targets netstandard2.0, and appbar targets .NET Framework 4.7.2.

Also, suppose libfoo uses FParsec. In particular, libfoo depends upon the FParsec NuGet package, version 1.0.4-RC3. Also, libfoo must reference FParsec types, even if in a trivial way, to cause libfoo to load the FParsec assemblies.

A suitable example libfoo.fs follows:

module libfoo =
    let p : FParsec.Primitives.Parser<unit, unit> = Unchecked.defaultof<_>
    let nonConst () : int =
        System.Environment.MachineName.Length

Finally, suppose appbar depends upon libfoo. In particular, appbar must load libfoo, by calling into libfoo.nonConst(). The last being non-constant is important; otherwise the compiler could optimize away the loading of the libfoo assembly.

Expected result

appbar calls libfoo.nonConst, and successfully receives a return value.

Actual result

appbar calling libfoo.nonConst causes an exception:

FileLoadException: Could not load file or assembly 'FParsecCS, Version=1.0.4.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Environment

I am using recent Visual Studio 2017 (v15.8.7), and NuGet (v4.8.1).

Non-causes and non-fixes

Many things can be changed or added, and still trigger this bug:

• Adding missing (or removing) AutoGenerateBindingRedirects to appbar's project file (.csproj or .fsproj) does not make this problem go away.
• Changing FParsec.dll and FParsecCS.dll's AssemblyVersion doesn't help. Whilst FParsec's AssemblyFileVersion/FileVersion is set as expected to e.g. 1.0.4.0, the AssemblyVersion tends to be set to 1.0.0.0. This surprised me. Regardless, changing AssemblyVersion to match AssemblyFileVersion/FileVersion does not solve the bug.
• downgrading libfoo's netstandard version to 1.6 doesn't help
• downgrading appbar's .NET Framework version to 4.7.1 doesn't help
• switching either or both of libfoo and appbar's languages, to C# from F#, doesn't help
• switching libfoo and appbar's project files (.csproj or .fsproj) between the "old style" (e.g. VS2015), and the modern style (MSBuild Project SDK) doesn't help

Also, this issue affects every version of FParsec with netstandard1.6 support, namely from 1.0.3 beta upwards.

Also, FWIW, I needed two projects, the libfoo and appbar: I could not reproduce the issue with only one project.

Workarounds

Now, this issue can be avoided by changing libfoo to target .NET Framework (e.g. v4.7.2), or changing appbar to target netcoreapp (v1.0, v1.1, v2.0 or v2.1). Unfortunately, this is not always feasible.

The above fact suggests to me that this could be a bug in the .NET Framework's support of netstandard.

Nonetheless, it may be easier and faster to work around this issue in FParsec. In particular, the issue can be fixed if FParsec targets netstandard2.0 instead of netstandard1.6. Weirdly, and in support of my supposition this is a .NET Framework bug, it is not enough for FParsec to target netstandard2.0 in addition to netstandard1.6

Next steps

Would you be willing to target netstandard2.0 instead of netstandard1.6? And if so, would you prefer a pull request, or to implement the change yourself?

Moreover, please ping me if you have trouble building an unmodified FParsec with the recent version of Visual Studio I am using. In particular, as a separate issue, there are some changes which might be required to the way FSharp.Core is referenced.

This would remove unsafe code from the CharStream and pave the way for one edition of FParsec for all use cases.

This StackOverflow question is what led to this feature request. I don't know the actual use case, but the example use case in that question is a parser setup similar to the following:

let comma = pchar ','
let numbers = sepBy digit comma
let dirChars = anyOf "ENSW"
let direction = comma >>. manyChars dirChars

This looks like it would successfully parse the string "1,2,3,NNW", but it will fail. The sepBy function will consume the comma after 3, see that the next character is not a valid digit, and fail because sepBy does not allow a final separator not followed by a valid list item.

In the case of this example, it would be possible to parse that string by using sepEndBy and changing the direction parser to a simple manyChars dirChars. But that would then pass when given the input "1,2,3NNW" (note no comma before the direction), and in some parsing scenarios it's likely that the comma between the numbers and the direction would be required, so the "1,2,3NNW" input should actually fail.

Having looked through the sepBy code pretty thoroughly, I think the best way to implement this request (allow sepBy to backtrack to the state just before the last separator if the last separator isn't followed by a valid list item) is to create a new sepBy variant. The existing sepBy implementation would require very little tweaking to implement this (instead of just checking the parser state before consuming a separator, actually save a backtrack point and then restore it if the separator isn't followed by a valid item), but the performance cost could be large (I don't know how much it costs to save a backtracking point that you're most likely going to throw away).

So to implement this feature request might actually require forking the existing Inline.SepBy implementation, which might be more complex than it's worth. But it's worth looking into, at least.

I'm hitting the infinite loop issue with the ErrorMessage.ExpectedString.String property. I see it's fixed in master, but hasn't been released yet.

Is it currently possible to ship a new RC for 1.0.4 from master or even release it?

I'd be glad to help in any way if needed.

I've recently adopted F# for a project, and it appears the entirety of the quanttec.com site has just died. It's totally unreachable, and I can't find another place to access the FParsec docs. Is this issue known, and is there any plan to fix it?

It causes problems with BenchmarkDotNet, and possibly, performance degradation.

I'm getting an issue with FParsec 1.1.1, the issue seems to come down to the FParsec package having assemblies with different version numbers for different target frameworks (net45 = 1.0.0.0, netstandard2.0 = 1.1.1.0).

Was it intentional that the net45 assembly has a different version number? It makes very hard to consume a netstandard2.0 library that uses FParsec, from a net472 assembly.

The issue is e.g. seen with Logary 5.0.1 which is netstandard 2.0 library and uses FParsec 1.1.1. We are not able to use that Logary in an .NET Framework project because Logary throws System.IO.FileLoadException on loading Logary.

Originally posted by @brian-reichle in #34 (comment)

I was wondering if there was not a way to get all the errors found by FParsec (in list form?) when you need the AST returned from a function. Here is the most frequently presented way of doing things:

let parse input =
    match run prog input with
    | Success(result, _, _) -> result
    | Failure(msg, _, _) -> failwith msg

With such a method, it is only possible to display one error at a time. This is not very desirable for an analysis to be performed on large files.

How could we do that? Is there a function that could be useful in this case? I looked in the documentation, and it doesn't seem to be.

Thank you.

Would it be possible to release a new version of this package that targets netstandard2.0 rather than 1.6? This has some benefits, one of which is that with the recent release of FSharp.Core 4.7, much simpler dependency graphs in Paket.

It seems that this package contains FParsecCS.dll build with x64 platform target. Is that on purpose, or by incident?

Hello, excuse me for disturbing you again.

This time, it's to ask a question about your Wiki, which has allowed me to make a lot of progress on my project to create a parser for a ML-like mini language.

As you will have understood, I therefore resort to indentation. However, I encounter some difficulties when I experiment with a more complex syntax than the one presented in the Wiki.

In your example, you parser this code:

loop i 1 10 10
  loop k 1 10
    print k
  print i
print j

I am now trying to analyze codes such as:

let foo = 2 + 1

or

let foo = 
    loop i 1 10
        print i
    2 + 1

These are of course examples for the preliminary tests.

In my implementation, I consider everything to be an instruction, but to be more precise and consistent, I named the instruction parser pexprs:

let pexprs, pexprimpl = createParserForwardedToRef()

The problem I have is the fact that the indentation module of your example always asks for a new line to parse everything waiting for an expression with the pexprs parser; that is to say all the other parsers. What is problematic....

Here is the post on which I posted my question on SO, and where I was able to solve a parallel problem, but this one still persists. (Please see the Edit on the SO link.)

Hoping of course not to disturb you, and waiting for a salutary answer from you; thank you.

BenchmarkDotNet does a verification of all dependencies to see if they have been built with optimizations on. It states fparsec cs isn't, fparsec itself is alright according to BDN (1.0.3 and 1.0.4-rc tested)

// Validating benchmarks:
Assembly PerformanceTests which defines benchmarks references non-optimized FParsecCS

https://github.com/dotnet/BenchmarkDotNet/