We've known for ages that with the {{{Q.Infix @ op}}} mechanism, we want data to flow from the type system to the parser (as in, after parsing that unquote, the parser has changed state as if it'd've parsed an actual infix; and also, we can do both static and dynamic type checking on op)...
...but it just recently dawned on my that the things in is parsed allow us to go in the opposite directly, informing the type system based on parsing details.
Example: if it says <expr> in the is parsed regex, then we can assume that the value that ends up in match["expr"] is a Q.Expr. (How are we allowed to assume that? I don't know exactly, but I don't consider the exact mechanism there to be a show-stopper. Hat tip to #52 which is sorta-kinda also about what we can assume about rules and Qnodes.)
In other words, we should be able to infer a lot about the contents of match, to the point where an IDE could autocomplete on its properties and their properties, etc.
This sort of forms the beginning of a "pluggable type inferencer", in the sense that here we have type inference information flowing in from is parsed and its regex, not from explicit type annotations. That's an intriguing thought, exposing that as something extensible in the language — however, that's out-of-scope for this issue.
We've known for ages that with the
{{{Q.Infix @ op}}}mechanism, we want data to flow from the type system to the parser (as in, after parsing that unquote, the parser has changed state as if it'd've parsed an actual infix; and also, we can do both static and dynamic type checking onop)......but it just recently dawned on my that the things in
is parsedallow us to go in the opposite directly, informing the type system based on parsing details.Example: if it says
<expr>in theis parsedregex, then we can assume that the value that ends up inmatch["expr"]is aQ.Expr. (How are we allowed to assume that? I don't know exactly, but I don't consider the exact mechanism there to be a show-stopper. Hat tip to #52 which is sorta-kinda also about what we can assume about rules and Qnodes.)In other words, we should be able to infer a lot about the contents of
match, to the point where an IDE could autocomplete on its properties and their properties, etc.This sort of forms the beginning of a "pluggable type inferencer", in the sense that here we have type inference information flowing in from
is parsedand its regex, not from explicit type annotations. That's an intriguing thought, exposing that as something extensible in the language — however, that's out-of-scope for this issue.