Open liufengyun opened 7 years ago
The initial results are in the branch https://github.com/liufengyun/gestalt/tree/parser.
The basic idea works well. However, in order to support quasiquotes, we need to adapt the parsing algorithm so that it does backtracking instead of inspecting parsed trees.
This is an interesting exercise to implement portable quasiquotes completely based on extractors and extractors. But I've no time to continue to experiment with it in a short term.
Could you elaborate on the potential benefits of a standalone quasiquote parser in comparison with the one implemented in Scalameta?
From programmers' point of view, there's no observable difference. But it's an interesting exercise, as I mentioned. It shows that the whole quasiquote can be implemented based on extractors/constructors .
In this exercise, does the parser also use constructors and extractors, or it is based on Dotty trees? From the existing code, I see that you're reusing the standard Dotty parser, but what are the long-term plans behind this idea?
It uses constructors/extractors throughout, no dotty trees. There's no plan on this, just review issues and document what I've done before on this.
Currently, gestalt depends on
scala.meta
to parse quasiquotes, the transitive dependencies forms a obstacle for the possible integration ofgestalt
withdotty
(if it ever happens).It's possible to copy the parser code from
dotty
to create a light-weight parser with zero dependencies. The parser uses toolbox directly to create trees.