Some random notes on what could be done with the package in the future. None of this is scheduled. Infrastructure -------------- write a CI script decide if to use a code formatter - pro: it will preserve git blame stuff better switch the website to use markdown try to improve the usability of the rendered test cases add automated tests for the examples on the website add a few more examples to the website: parse some sql and detect if it has a particular feature do a transformation on some sql idea: convert tpch to sql server syntax generate some sql format some sql check if some sql parses trivial documentation generation for ddl trivial lint checker demos: crunch sql: this takes sql and tries to make it as small as possible (combining nested selects where possible and inlining ctes) expand sql: breaks apart complex sql using nested queries and ctes, try to make queries easier to understand in stages write a beginners tutorial for how to add support for some new sql syntax show how to develop parsers interactively, then tidy them up for merging to the main branch review code coverage and see if there are any important gaps to fill in set up hlint to run easily Code ---- There could be more negative tests for lexing and dialect options. Check the fixity in the tableref parsing, see if there is anywhere else that needs tweaking. Do all sql dialects have compatible fixities? If not, want to add dialect control over the fixity. add parse error recovery add ability to type check: uuagc still seems like the nicest option? uuagc has an option to attach to an external ast now, so could put the type checker in a separate package figure out how to support parsing some sql, transforming it, pretty printing it while perserving as much of the original formatting as possible, and all the comments an intermediate step is to minimise the difference in non whitespace/comment tokens when you parse then pretty print any supported sql add an annotation field to the syntax to make it more useful add source positions to this annotation when parsing can you make it properly extensible? the goal is for users to work with asts that represent only the dialect they are working in review names in the syntax for correspondence with sql standard, avoid gratuitous differences reduce use of booleans in the syntax quasi quotation support use this lib to build a typesafe sql wrapper for haskell optimise the lexer: add some benchmarks do some experiments with left factoring try to use the match approach with megaparsec see if it's work using something other than megaparsec for the lexer or// maybe it's no longer worth having a separate lexer? rewrite bits of the parser, lots of it is a bit questionable - an expert with megaparsec would write something simpler I think it's not worth doing for the sake of it, but if a bit is too difficult to add new features to, or to improve the error messages, then it might be worth it work on error messages review the crazy over the top lexer testing maybe it's enough to document an easy way to skip these tests check more of the formatting of the pretty printing and add regression tests for this is there a way to get incremental parsing like attoparsec?