Quote constant extraction

[nicolasstucki]

Add quoted.Contant.unapply.

val e = '(3) // '
e match {
  case Constant(n) => // get n with value 3
  case _ => // e is not a constant
}

Based on #3685

[liufengyun]

A conceptual question, how does Expr[T] going to interact with tpd.Tree?

I see we have ConstantExpr for literals, what about other trees, e.g. Apply, Block and If-Else? Are we going to create another hierarchy of Expr[T] trees for extractions?

[liufengyun]

We should leave design space for other extractors as well. Some thoughts:

• it's better all extractors are located in the same file (as there aren't many)
• the name runner doesn't make sense to programmers.
  • FYI, in gestalt it's called Toolbox, in macros it's called Universe.
• ConstantExpr can be removed, and Liftables could be implemented with an implicit Runner

[nicolasstucki]

Needing an implicit Runner is something that should be avoided. That would create an unnecessary dependency on the compiler/toolbox. In the current design, if you only quote, splice and inline the user never needs to add the runner.

[liufengyun]

Thanks for the explanation. I just want to point out another logically consistent design. As long as the design tradeoffs are clear, I think it's fine to optimise.

[nicolasstucki]

In essence, the runner is equivalent to the toolbox except that we only use it to interpret expression at runtime (compile and run, show and deconstruction). The constructor are the quotes themselves, '(if (~cond) ~e1 else ~e2) is the constructor for an if expression. The only missing constructor is for literal constants from runtime primitive values, which we special case in ConstantExpr. It is true that having ConstantExpr is more performant but it is not an optimization. Thought we could decide to compile '(5) to a ConstantExpr to avoid the pickling memory and runtime costs.

[nicolasstucki]

rebased

[nicolasstucki]

CLA is failing for no reason but CI passes