Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full quasi-quoter #15

Open
achudnov opened this issue Aug 23, 2013 · 0 comments
Open

Full quasi-quoter #15

achudnov opened this issue Aug 23, 2013 · 0 comments

Comments

@achudnov
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant