Cannot quoted-match a function with a closure

[deusaquilus]

Minimized code

Say you define a simple function that takes an inline closure:

object FunObject {
  def fun(t: String => String) = t
}

If you try to match the function call and the body of the closure like this:

case '{ FunObject.fun(($arg: String) => $out) } =>

This will never match.

Additionally, if you try to use the $arg parameter e.g. println(arg.show) the following error will happen.

[error] 15 |          println(arg.show)
[error]    |                  ^^^
[error]    |                  Not found: arg

Expectation

The closure should match and you should be able to extract the $arg and $out parameters.
Using quasi-quotes, I am able to do this:

case q"FunObject.fun(($arg) => $out)" => 
  process(arg.name.decodedName, out)

I depend on this pattern heavily in the Quill Parser. I think quoted-matching should have the same capability.

Code Sample

Code sample with complete reproduction can be found here:
https://github.com/deusaquilus/closure_bug

[LPTK]

I think the current macro system does not support $ in binding position. So it looks like you're matching a lambda while naming its parameter literally $arg, which is why arg is not in scope.

I thought the way you're supposed to do it was:

case vv @ '{ FunObject.fun((arg: String) => $out(arg)) } =>

to get an out: Expr[String] => Expr[String].

But it doesn't type check, I don't know why (cc @nicolasstucki).

This type checks but is useless:

case vv @ '{ FunObject.fun((arg: String) => ($out: String => String)(arg)) } =>

as it gives us out: Expr[String => String].

There have been talks about allowing extracting open code by keeping the scope dependencies encoded in the types like in Squid, but I don't think this has been worked on yet.

[nicolasstucki]

There is a limitation with type inference that I need to fix. In theory, we will be able to match on the first option.

One simple way we could expose the name of the argument is be adding a helper method

/** Return the name of the parameter of an explicit lambda */
def argName(f: Expr[String => String]): String = f.unseal match ... // or maybe return an Option

An important note is that '{...} and q"..." are fundamentally different. The first works on well typed and scoped expression while the other works on trees. Hence, '{...} will be more restrictive and safer.

[nicolasstucki]

We could also detect names that start with $ in patterns and emit a meaningful warning.

[nicolasstucki]

Inference will improve with #8766