State and stack for type checking

[leafo]

When the addition of tags, I added a state object that is passed down to type checkers as a object is checked.

Currently state is internal only for tags, but it can be exposed as part of the public API so you can write type checkers that can have side effects for other subsequent type checkers. There's two scenarios

• Adjacent state — In the * sequence of operator, a previous type checker could put some data in to the state object that a subsequent one can read.
• Nested state — when type checkers are nested, a inner checker could put something on the state that the parent one checks. Type checking happens depth first right now. Additionally, before calling nested type checker, the parent could put something on the state to let a child read.

Because of how type checkers are nested it makes sense that the state object could represent some kind of stack. The simplest addition would be to leave the instances of the type checkers on a stack array in the state. This way a child could search up the stack to get some idea about how it's being called to affect what it does. (maybe like jquery, or how web_sanitize's query selector stack works)

The current use-case that I'm using to think about this functionality is MoonScript AST transformation. A transformation changes depending on whether a local variable is in scope or not. Being able to keep track of which locals have been assigned directly in the type checker's state makes the most sense.

[leafo]

There is now types.scope and a bunch of general purpose state manipulation functionality. Unfortunately type context aware types are still impossible, a type can't query who called it. No plans at this time to add this functionality due to the complexity. If you wanted to build a system with your own types you could implement this using state objects