Decoupling Macros in ReifyQuotes

[nicolasstucki]

Transforms macro implementations from

object PowerMacro {
  inline def power(inline n: Long, x: Double) = ~{
    if (n == 0) '(1)
    else powerCode(n, '(x))
  }

  def powerCode(n: Long, x: Expr[Double]): Expr[Double] = ...
}

to

object PowerMacro {
  inline def power(inline n: Long, x: Double) = ~power$splice$1(n, '(x))

  def power$splice$1(n: Long, x: Expr[Double]) = ~{
    if (n == 0) '(1)
    else powerCode(n, '(~x))
  }

  def powerCode(n: Long, x: Expr[Double]): Expr[Double] = ...
}

This way the inlined code is always a static method with a single list of arguments. Which is easy to interpret when inlined. This transformation is performed before pickling to ensure the new body will be inlined.

This implementation is also a first step to fix #4801 and #4803.

[odersky]

I must admit I understand none of this. Before proceeding, I propose to write a document explaining the transformations in detail. Not just this one, but everything relevant to how code with toplevel splices is transformed to code that can be run.

[odersky]

"to macro bodies"

[odersky]

(?) Should be two sentences, maybe?

[odersky]

What if the original splice is already of the form

~bar(...)

In that case, we can simply forward to bar, no? Would it not be simpler to require that all toplevel splices are of this form?

If we do have a requirement like this, what is the added benefit of the phase?

[odersky]

Where does foo come from. It does not appear in the input.

[nicolasstucki]

Here is a description of how this phase should work (gist). The current implementation does not mach the description, but it should be addapted to it.

[odersky]

We have two concerns here:

1. Where can the inline method be placed? I'd say, best are no restrictions at all.
2. What is a legal right hand side? Ideally, anything, but here I am willing to compromise to
   say it must be a call of the form ~f[...](....) where f is a static method.

If we do implement that restriction, the phase becomes redundant.

What is the price for allowing more flexibility in the right hand side? We must find a suitable location for the static method, with suitable parameters and so on. This looks pretty hard! It will require at least a call to FulllParameterization to account for all possible combinations of enclosing parameters and so on. But the problem is even harder if we also want to support local inline methods that can refer to type parameters of enclosing classes.

So, since we do not want to compromise (1) over (2), and (2) does not look really important anyway, I'd be in favor to impose the restriction and close the PR.

[nicolasstucki]

Instead, I will implement the proposed simplification. I extracted useful cleanups from this PR in #4818