Parsing context about pidgin HOT 4 CLOSED

Do you have an example of what you would like to do with ParsingContext?

from pidgin.

I have a complex parser that forms the elements in the process. Several of these elements need a context in order to read the previous parsed result from it.

I could pass the context along with char, but it looks terrible and the construction is difficult read : Parser<(char, IParsingContext), string>

from pidgin.

@benjamin-hodgson what do you think about it?

from pidgin.

1. Early on in the design of Pidgin I decided not to support a custom user state object, at least not via a third type parameter.
   • It's already tedious to repeat eg Parser<char, MyExpr> all over the place (doubly tedious since TToken typically doesn't change), so adding a third type parameter (Parser<char, MyState, MyExpr>) seemed excessively wordy.
   • It'd also mean threading an additional type parameter through all of the API functions (and through users' custom combinators)
   • There are legit design issues, such as what to do with user state upon backtracking.
   • So basically, while I certainly acknowledge that there are legit use cases for user state, I think it exceeds the complexity budget. Perhaps I made an early design mistake by prioritising custom input tokens over user state (for what it's worth, FParsec made the opposite decision) but it's much too late to reconsider that.
2. I am open to providing an untyped slot on the ParseState<TToken> struct (ie public object UserState { get; set; }) possibly with an untyped high-level API, for those who definitely need it.
3. However - being unfamiliar with your requirements and having not seen your code - I'm not altogether convinced that you are one of those people who need it. "Several of these elements need a context in order to read the previous parsed result" - there are a number of existing ways to get at a previous parsed result. Do Then/Map/from...select/parameterisation/etc not suit your needs?
   • User state is really for when the grammar depends, in a non-local way, on previous parse results. (An example of this would be indentation-based languages.) In your case it sounds like the result depends (locally) on previous results.
4. I don't think plumbing it in through that first type parameter is likely to work in any case. That's the type of the tokens in the input stream, there isn't any way to write things into it from inside a parser.

from pidgin.