45669ed7d3
move exe example to examples/ get rid of the second example move tests to tests/ don't shadow show in Pretty
98 lines
3.3 KiB
Plaintext
98 lines
3.3 KiB
Plaintext
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?
|