Closed leafo closed 1 year ago
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
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
*
sequence of operator, a previous type checker could put some data in to the state object that a subsequent one can 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.