I'm writing a type checker for Clojure code that utilizes a modified version ClojureScript analyzer.
I have made some changes to the analyzer to analyze Clojure code, instead of ClojureScript.
These changes could form the basis of a generalized analyze library to be called a la carte.
Analyzer doesn't understand macro definitions (defmacro's)
- Solution: `require` namespace before analysis
- assuming a macro is only defined once
- compiler should pick up any uses of the macro before definition, so don't need to know where in the namespace macro is defined
Dynamic loading and aliasing
- ClojureScript has no compiler at runtime, so all dependencies and aliases are known at compile time
- Clojure has `refer`, `require`, `import`, `alias`
- Can be called dynamically at runtime
- Impossible to compute all dependencies at compile time
- Seems like a losing battle
- Could we analyze clojure.core? Uses dynamic `load`, `require`
- Could compromise, warn on unresolvable alias/require, then assume analyzer cannot be trusted
- allows them to be scattered around the file (like clojure.core),
- should be good enough to analyze clojure.core
- which seems like a reasonable goal
- assume namespace information is more volatile
Instead of propagating the `(:ns env)` of the `do` to its children (as in CLJS), should lookup namespace information for each form (but propagate locals and any other `env` keys as normal)