On part2 couldn't you keep the parser from part1 and insert a mutually recursive function before the regex from part1. Something like `let rec splitOnDont enabled remainder = if remainder = "" then enabled else let [|e;r|] = lines.Split("don't()", 2) splitOnDo (enabled + e) remainder and splitOnDo enabled remainder = if remainder = "" then enabled else let [|_;r|] = lines.Split("do()", 2) splitOnDont enabled remainder`
That sounds doable, yes! I'm waiting on a more complex parsing puzzle so I can play around with parser combinator libraries again, those do a lot of that recursive "remainder" and backtracking heavy lifting for you. Have you played around with FParsec? It's got a bit of a learning curve but it's worth the effort if you have to do non-trivial parsing: www.quanttec.com/fparsec/
On part2 couldn't you keep the parser from part1 and insert a mutually recursive function before the regex from part1. Something like `let rec splitOnDont enabled remainder = if remainder = "" then enabled else let [|e;r|] = lines.Split("don't()", 2) splitOnDo (enabled + e) remainder and splitOnDo enabled remainder = if remainder = "" then enabled else let [|_;r|] = lines.Split("do()", 2) splitOnDont enabled remainder`
That sounds doable, yes! I'm waiting on a more complex parsing puzzle so I can play around with parser combinator libraries again, those do a lot of that recursive "remainder" and backtracking heavy lifting for you.
Have you played around with FParsec? It's got a bit of a learning curve but it's worth the effort if you have to do non-trivial parsing: www.quanttec.com/fparsec/