Closed liufengyun closed 7 years ago
The downsides of this approach are:
All in all, despite the downsides I think this approach has much potential. It would seem that the issues that we faced in reflect (https://github.com/scalamacros/macrology201) are simply impossible in the new design. Let's experiment.
@xeno-by I remember you mentioned below and it's agreed:
Just log down to confirm, please correct me if I were wrong.
That's how I understood our discussion as well.
I cannot commit to big architectural things like that on the spot, but the design is very compelling, and it definitely merits experimentation.
It has an assumption on the compiler side: they must have a concept called TypedSplice
I guess, otherwise, things will not work reliably.
Another implementation-driven decision is to have untyped quasiquotes and typed quasiquotes support different subsets of the language. In the ideal world, we would provide the users with an API that supports for loops and other syntactic sugar in typed quasiquotes.
If it simplifies something, I'd propose disallow Quasiquote as patterns completely. It seems to me it's always easier to use extractors directly and reliably. Le 28 avr. 2017 19:16, "Eugene Burmako" notifications@github.com a écrit :
Another implementation-driven decision is to have untyped quasiquotes and typed quasiquotes support different subsets of the language. In the ideal world, we would provide the users with an API that supports for loops and other syntactic sugar in typed quasiquotes.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/liufengyun/gestalt/issues/62#issuecomment-298055755, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuDyVJGs4Be2wggU3Wyf4nGi5n0CpPiks5r0h7_gaJpZM4NLqEM .
As the experiment in #67 shows, quasiquote-based patterns are useful for typed trees. But in annotation macros, users usually inspect def trees which have to do with modifiers and options, in that case extractor-based patterns are better.
From the observation above, maybe we can take the following compromise:
In def macros, there is also the need to embed untyped trees inside typed trees, e.g. transform one pattern in the body of a method.
In this case, it seems the enclosing typed tree has to downgrade into untyped trees completely via some non-trivial rewriting.
If we restrict that the trees passed to DefMacros cannot contain class
, trait
, object
and def
(val
is fine), then life is much easier -- a lot of problematic macros can be prevented in the beginning.
But I'm not sure if it's a good limitation.
Due to the use case of modifying a small piece of code in typed trees, toolbox.type(tree: untpd.Tree)
can help to ease the problem. However, we should also allow programmers to compose typed trees for the whole scheme to work.
Mixing typed trees with untyped trees cause problems in the compiler. As discussed in the meeting:
Splice
.Splice
should be as transparent to macro writers as possible