bounty 4 - clarification & proposal

Trying to clarify my understanding of bounty 4 with what I read from the current Gno repo, is the end goal to be able to replace the current golang parser (adapted in go2gno.go) with this new PEG implementation?

If so, would the following overall plan look reasonable?

Step 1: have a minimalist implementation of a PEG parser in the Gno repo, this implementation doesn't have to be feature complete, mostly to get used to the coding style of the project and have something that can be moved in the right direction,
Step 2: start implementing the Gno syntax with small Gno code examples with the PEG parser (likely improve the way the initial PEG parser works in the process), have a sort of tool/small process to compare the produced AST with the one from the current go parser,
Step 3: iterate until we end up at the stage where we have a near-complete support of Gno (I guess when all examples from files/test have a proper AST),
Step 4: rework go2gno to use the Gno parser using PEG (or alternatively, have a period during which we can switch between the two implementations until we get enough confidence the PEG approach yields correct results),

Some open questions:

Are there other potential use-cases of this PEG parser in the current codebase?
Would it make sense to eventually have this parser written in Gno itself?

I'm unsure at this stage how far I will go; I think it's important to do this incrementally, in small steps going in the right direction, so that it's useful in case other folks want to be involved. I have some experience writing BNF parsers and rules to handle ASTs for C in the past, not sure it will help here but I think I kind-of see where most of the time will be spent.

If that sounds reasonable, I'll try to come up with a clear plan for Step 1, after playing a bit more with the current codebase.

gnolang / bounties

bounty 4 - clarification & proposal #29