Closed 0rphee closed 1 year ago
Indeed, runParserST
should return in ST s (Result e a)
if we want to be consistent with runParserIO
. We can always just runST
the result. I think this actually merits a mild breaking change here. I'll push this on hackage shortly.
In 1559b56a0feafb93661675fb406bc66894115fda. Pushed to hackage.
The already existing function to run parsers in the ST monad has this definition (using the Stateful version):
This is fine for some ST computations, however, if for whatever reason I want to use this parser inside a larger ST computation, or with the use of a STRef (instead of using an MVar for example), it is impossible to do so.
This came up as a problem I found when trying to collect multiple parsing errors. Initially I just exited the parsing with an error, though obviously this only collected the first error and stopped there. Then I used MVars succesfully, and tried to go with STRef's.
Using the Stateful version, with an
STRef s ScanErr
as the reader environment, I found that the already existingrunParserST
function didn't work for this usecase:Very possibly I'm just contorting myself to do this with ST instead of IO. However, if it is possible to do this way anyways, why not? haha!
So I hacked together this alternative function, following from the implementation of the original
runParserST
:I think it would be very nice to make something like this available to any
flatparse
user. This version has worked fine for my usecase, though I don't know much intricacies about how ST/IO work to guarantee that this function will be safe, and if it were, I don´t know how to generalize this, since not everyone might want exactly an environment of typeSTRef s c
Anyways, I thought sharing this with someone more knowledgeable than me would be worthwhile.
Thanks for the great library!