Separate typed tree from untyped tree

[liufengyun]

Mixing typed trees with untyped trees cause problems in the compiler. As discussed in the meeting:

• Typed trees and untyped trees take different types
• Neither is a subtype of the other (unlike in Dotty)
• Typed trees can be wrapped in untyped trees by a special untped tree: Splice.
• Splice should be as transparent to macro writers as possible

[xeno-by]

The downsides of this approach are:

• Different families of types that mostly duplicate each other
• Weird names for quasiquote interpolators (because interpolators can't be qualified by normal means)
• Possibly unwarranted cognitive burden on users

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.

[liufengyun]

@xeno-by I remember you mentioned below and it's agreed:

• the return type of macro expansion is untyped tree
• user can only use quasiquote to construct untyped tree (with possible typed splices)
• user can use quasiquotes to destruct both typed trees and untyped trees

Just log down to confirm, please correct me if I were wrong.

[xeno-by]

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.

[liufengyun]

It has an assumption on the compiler side: they must have a concept called TypedSplice I guess, otherwise, things will not work reliably.

[xeno-by]

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.

[liufengyun]

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 <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuDyVJGs4Be2wggU3Wyf4nGi5n0CpPiks5r0h7_gaJpZM4NLqEM> .

[liufengyun]

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:

• quasiquote construction only for untyped trees
• quasiquote patterns only for typed trees

[liufengyun]

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.

[liufengyun]

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.

[liufengyun]

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.