Discussion: using a "parsing" library

@alanmcruickshank I see that the project implements its own parsing primitives from scratch in parser/, I’m curious if you think introducing a dedicated library like parsy would be beneficial (I picked a parser combinator because it’s close to the pattern we’re using).

IMO that could mean less code to maintain on our end, and less concepts that people need to get “familiar with” if they want to contribute to the parser (and are familiar with parser combinators). I’d hope we would get performance improvements too!

[barrywhart]

@dmateusp and I had a brief discussion on this topic in the context of #325, which surfaced a tricky parsing ambiguity with angle brackets and relational operators. I think we are converging on a conclusion that we have a workable approach for now, so using a parsing library is not needed, at least for the foreseeable future. Should we close this ticket?

[dmateusp]

So I will take your requirements list @alanmcruickshank and your concerns @barrywhart and try to implement a POC that satisfies both, or at least illustrates what’s not working!

We (at Earnest) use a parsing library often which follows the same principles as parsy (but in Haskell) to validate CLI inputs, the most complex use of it we have (that I’m aware of) is translating Glue API responses into types to do a translation from a Glue Schema to a Snowflake Schema.

For these use cases in my opinion we end up with very readable and re-usable code, but I haven’t done anything as complex as what is done in sqlfluff, so it’ll be interesting!