Imagine that I have simple string (in reality this string can contains much complex items like digit combination, Guid etc...): "a, b, c" and appropriate parser which works great with it.
Then after some changes string becomes: "a, b, c, d, e" Parser has been rewritten in manner to aim successful result.
But now I have to be sure that rewritten parser doesn't fail on parsing old format string. Is it possible to provide backward compatibility with FParsec?
The backward compatibility should be implemented within your data model, and make the parser only to support this data model.
Say, if your Result datatype is a List<> (which is intended to be 3-elemens long), only a minimal intrusion makes the parser return a 4-element data. You then check data validity with your application logic, and you're all set.
However, if your Result is a fixed tuple/triple like T1 * T2 * T3, there is no straightforward way to add the fourth element. You would probably need an extra layer — usually implemented as a Discriminated Union (DU), like this:
type MyData =
| OldFormat of T1 * T2 * T3 // this is your old way
| NewFormat of T1 * T2 * T3 * T4 // this is your new data format
This way, you will have to implement a wrapper DU and also duplicate the parsing logic to support the 4-element data.
Check this, this, and this answers for some simple ways of parsing the "list of either-either" data.
Unless you provide with the existing code, it is hard to tell anything further.
