You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The quasi-quoter is very limited right now as it doesn't support anti-quotation. Full support for anti-quotation would allow using it in programmatic construction of syntax trees and pattern matching (which is a very powerful tool that saves a lot of time).
However, it would require potentially significant changes to the parser and the AST. Ideally, the parser should be able to work in two modes: quasi-quotation in which it recognizes the anti-quotations (I suggest using $x where x is any valid Haskell name) and normal where it doesn't recognize them and, thus, stays standards-compliant.
The second complication is that the usual ways of implementing quasi-quotation requires including a separate AST constructor for a anti-quoted categories (e.g. expressions). However, anti-quotations cannot and should not be pretty-printer, which would mean the user would be able to construct AST's that can't be pretty-printed. One solution could be restricting the valid AST's (e.g. the ASTs that can be constructed manually by the programmer) to exclude anti-quotations -- and we can apply that restriction using GADTs.
However, GADTs are quite unwieldy. And they are not enough to restrict ASTs to valid completely --- that would require some form of dependent types (e.g. for valid statement labels).
I think the best approach is as follows: have two different families of data-types representing ASTs. The first ---the representation of abstract syntax of ECMAScript--- is generated by the front-end parser, accepted by the pretty-printer and is visible to the user (both for inspection and construction). The other features additional syntactic productions that represents anti-quoted statements, expressions etc. It is only generated by the quasi-quoter parser and is not visible to the user. The challenge this approach presents is that of code duplication and the inevitable bugs/bit-rot that it generates. I think we can mitigate it using two language features: type-classes and Template Haskell. We can use Template Haskell to assist the definition of the anti-quoted ASTs from the front-end non-quoted AST. We use type-classes to specify code-generation functions (basically wrappers around the AST constructors) that have already proven their use independently, of which both ASTs are going to be instances. The parser then could use the type-class methods for generating resulting ASTs and be parametrized by the type of the AST. Together with simple logic to enable parsing of anti-quoted syntax, this should allow using the same parsing code for both the front-end and the quasi-quoter parsers --- which increases modularity and eliminates code duplication (hopefully reducing the errors).
The text was updated successfully, but these errors were encountered:
The quasi-quoter is very limited right now as it doesn't support anti-quotation. Full support for anti-quotation would allow using it in programmatic construction of syntax trees and pattern matching (which is a very powerful tool that saves a lot of time).
However, it would require potentially significant changes to the parser and the AST. Ideally, the parser should be able to work in two modes: quasi-quotation in which it recognizes the anti-quotations (I suggest using
$x
wherex
is any valid Haskell name) and normal where it doesn't recognize them and, thus, stays standards-compliant.The second complication is that the usual ways of implementing quasi-quotation requires including a separate AST constructor for a anti-quoted categories (e.g. expressions). However, anti-quotations cannot and should not be pretty-printer, which would mean the user would be able to construct AST's that can't be pretty-printed. One solution could be restricting the valid AST's (e.g. the ASTs that can be constructed manually by the programmer) to exclude anti-quotations -- and we can apply that restriction using GADTs.
However, GADTs are quite unwieldy. And they are not enough to restrict ASTs to valid completely --- that would require some form of dependent types (e.g. for valid statement labels).
I think the best approach is as follows: have two different families of data-types representing ASTs. The first ---the representation of abstract syntax of ECMAScript--- is generated by the front-end parser, accepted by the pretty-printer and is visible to the user (both for inspection and construction). The other features additional syntactic productions that represents anti-quoted statements, expressions etc. It is only generated by the quasi-quoter parser and is not visible to the user. The challenge this approach presents is that of code duplication and the inevitable bugs/bit-rot that it generates. I think we can mitigate it using two language features: type-classes and Template Haskell. We can use Template Haskell to assist the definition of the anti-quoted ASTs from the front-end non-quoted AST. We use type-classes to specify code-generation functions (basically wrappers around the AST constructors) that have already proven their use independently, of which both ASTs are going to be instances. The parser then could use the type-class methods for generating resulting ASTs and be parametrized by the type of the AST. Together with simple logic to enable parsing of anti-quoted syntax, this should allow using the same parsing code for both the front-end and the quasi-quoter parsers --- which increases modularity and eliminates code duplication (hopefully reducing the errors).
The text was updated successfully, but these errors were encountered: