todo

= next release, 0.5.0

see bigplan for some details

review and fix some of the syntax?

start thinking about how to support both postgresql and sql server better
  maybe stick with postgresql as guide for abstract syntax
  add bits from sql server where they don't have a parallel in postgres
  add a flag to only parse postgres or sql server constructs
  add a flag to pretty print in postgres or sql server
  maybe add a syntax check to check an ast value is valid
    - this check could cover a bunch of other things which are
      syntactically possible because of the design of the ast types,
      but don't represent valid concrete syntax

idea for :: cast

-> parse typenames as scalarexpressions by embeddeding them in
   numberlits (hacky but should be unambiguous)
then transform to cast after parsing. This can then use the proper
precedence in buildExpressionParser to parse ::. Also produce parse
errors if after parsing, you try to cast to something which isn't a
typename

= 'arcs'

== names

the typechecker ignores the new name structure which is able to
syntactically distinguish quoted identifiers and schema names

alter some of the catalog data types and support functions to work on
names or namecomponents instead of strings: mainly in the catalog and
local binding stuff

== localenv

New approach to fixupidentifiers in IDEnv. Want to use this approach
for typechecking local identifiers. Also can have more control over
rewriting the syntax. At the moment, it always adds in aliases and
correlation names all over the place. Want to make this optional, and
the ability to only add correlation names and not aliases. Want to
also get rid of the separate fixupidentifiers pass.

== typesafe wrapper

write typesafe wrapper for haskell accessing database big question is
which record system to use: haskell records, hlists, haskelldb
records, maybe fc-labels?

nullability inference would be useful here, also possibly single
column in result specialisation, and static check of single tuple in
result (e.g. where on key, or non grouped aggregates).


== api
review api names, docs and other aspects

== website nav

== examples

add compilation of examples to automated tests, also add tests in the
documentation

== nullablity inference in type checker

== syntax refactoring

lots of messy bits in the syntax:

some renames - try to follow the sql standard reference better

split out the plpgsql statements to separate ast node

have parens explicit in the ast?

more faithful representation of source code? This is mainly for
defaults, e.g. can't tell after parsing if an order by element was
explicitly asc, or implicitly asc. This might be useful for lint
checking e.g..

== ag - review code add fixmes
review ag code (and other code?) add fixme notes

== ag - literal source and haskell syntax

change the ag code to use .lag, and to use the haskell syntax
option. This should make understanding the code much more simple. One
possible goal to work towards is to make the main ast source file look
just like haskell, and to be able to edit it as if it was
haskell. This may need an additional codegenerator for compiling to
add in the ag boilerplate.

== ag - typechecking flow

the ag attributes and flow between sem rules is a bit confused at the
moment. In particular want to remove the extra 'inferred type'
annotation, also want to remove the cycles reported by uuagc by being
a bit more regular and disciplined (the cycles don't seem to have
caused any real issues however).

== typechecking regressions fix
lots of disabled tests, get them all passing again

== chaos

work on the chaos example
* get it typechecking OK again - lots of work on typechecker needed
* get the unit tests running again: maybe quickest is to port to new haskelldb
* get the ui running again so you can actually see it running
* maybe port these over to hssqlppp typesafe access for dogfooding
* fix the documentation generator which shows the translated sql -
  fair few prerequisites to this
* use new custom syntax stuff
* use the sql documentation generator (from the catalog)

add parsing and typechecking chaos (+ others?) to automated tests

== doctool

get the standalone doctool working. Get the website documentation
generator working again

== h7c

work on the functionality. want to get it working as a library to
compile chaos without needing to look at the hssqlppp lib
internals. The main blocker is fixing the syntax and then exposing the
parser internals for extension use.

== catalog work

the catalog holds pretty limited information at the moment, and
doesn't use that information to type check ddl very well (e.g. reject
drop on non existent objects, don't allow two tables with same name,
etc.)
so
* add much better error checking
* add much more information to support error checking
* track more types of objects, e.g. triggers, indexes
* add more information to support documentation generator, e.g. view
  source, function source, cross-linked hypertext sources

== quasiquote work

in addition to fixing the anticonstructor hiding above, want to add a
lot more quasiquotes. Good start would be to review all the
extensions, and translation examples, codegen, etc.. and make sure you
never need to write asts out explicitly, and can always use
quasiquotes.

Another thing to add is full haskell syntax inside quasiquotes. No
idea how to do this but the language-c-quote package does this so can
look at the source there.

== refactoring

review the code and refactor the crufty bits. Also want much better
documentation in the .lhs. Main code to completely rewrite is
TypeConversion.lhs which was written when I didn't know haskell very
well.

== error handling

review to eliminate any errors being hidden, or calls to 'error'

== custom syntax plugins

want to be able to plugin new syntax into parser - so alter syntax
tree as well. maybe start with the ability to add new statement types,
and new expressions types only.

== work through pg manual to get more complete coverage of sql syntax

== roundtrip testing

use postgresql to help with testing:

parse ddl, get catalog
load sql into postgresql, read catalog from pg
compare
dump database, parse dump and check catalog from hssqlppp is the same

parse sql
load into postgresql
dump
parse again
check is equivalent (might be very hard in general case)

some quickcheck style testing:
generate random ast
(maybe stick to scalar expression to start with?)
typecheck with hssqlppp
load into postgresql and get type out
check types are the same

== report generator

the idea is to have the following for experimentation, evaluate how
   well hssqlppp supports some existing sql, support while developing
   sql (possibly with syntax extensions), and generating
   documentation:
take source sql:
standard postgresql sql in text files
sql taken from postgresql dump from live db
syntax extended sql in text files
do some or all of the following:
parse and type check - report problems
parse, pretty print, reparse and check
generate documentation, catalog
load into postgresql and double check catalog from typechecker
load and dump postgresql, reparse and typecheck for changes

== documentation generator for sql codebases

== fix operator parsing
fix expression parsing and custom operators: stage one is to do a hack
which supplies the parser with the operator details at run time so
there is some flexibility

full dynamic support: e.g. create operators in sql then able to parse
use of them ... standard way of dealing with operator precedence is to
parse them all as left associative then adjust the tree after, not
sure this will be enough -> perhaps can reuse the haskell-src-exts
fixity thing for rewriting trees - will have to add parens explicitly
to the ast and parser, which might be tricky for sql?

== write extensions?

materialized view, temporal data, generalized inclusions, order
independent ddl source, show used catalog, modules for sql source

== lint

lint tool framework - so want to make it easy to add new rules

== separate parse tree?
consider having separate parse tree to the ast - can this be
automatic, or should it be a 'fake' parse tree

== better annotation approach?

maybe try to parameterize on annotation type? lots of other techniques