refactor analyzer #177
Description
The current implementation of the analyzer is somewhat slapdash, an accumulation of technical debt and learning experiences over the year. it's partially tools.analyzer, but then it does its own typed passes. flowing types in particular is a bit haphazard. it all works, but it would be better if the foundation was more solid.
ideally the analyzer would stick to a strict functional pipeline discipline with a progression of passes that transform AST nodes from the initial parse tree into something ready for compilation. I don't know that we need pass scheduling.
some lessons learned/things to try:
- pull metadata into AST hash maps as early as possible. relying on metadata is a pain.
- the current analyzer cannot be specialized the way the compiler can with its compiler map. it could be powerful to enable that approach in the analyzer.
- it might make sense to store the inferred type of each node as a key in the node itself