Implicit modifiers fall off from ValDefs about squid HOT 6 CLOSED

This is by design. Squid's normal mode of operation is to manipulate trees that are fully resolved: fully typed and fully applied (including implicits), so the fact that a local value be implicit has no incidence on the program after type checking.

That said, I assume you have a good use case for it. Perhaps you want to insert some code within the body of that let binding where some implicits are not resolved yet? If that's a necessity for you, I think we can keep track of the implicit modifier and generate code that reapply it (this would likely be done staring from there).

Let me know what's your stance on it. What is your use case?

from squid.

Oh, I see!

Unfortunately, we need to keep the implicits unresolved in most parts of Emma's pipeline, and resolve them only at the end. (This is because some Flink implicits resolve to scary stuff that we can't handle at the moment, for example anonymous classes like new Foo {...})

So it would be good if Squid kept the implicit modifiers on the ValDefs, because then we could still resolve them at the end.

from squid.

Okay, that makes some sense. However, you're probably going to have troubles if you try to handle these Flink functions in quasiquotes. Remember that Squid quasiquotes are type-checked and will require the implicit arguments to be inferred or provided.

A way around this (if you do need to manipulate these constructs explicitly) would be to define a mirror of each construct but without the implicit parameters, and only at the end of the day, when generating code, you change them back to the actual Flink functions. (The mirror definitions could actually be macros that expand into the Flink functions automatically on compiling the program using scalac.)

I'll look into the implicit val thing. Note that a workaround could be to encode implicit val a = t; ... as withImplicit(t) { a => ... } and either manually convert them back during code gen or use the macro trick mentioned above.

from squid.

Thanks for looking into this! I'm thinking of an other workaround now, which avoids having to define the mirrors:
Let's say that the user's code is calling some Flink method:

x.flinkMethod

which has some problematic implicit parameter that, say, looks like this after resolution (before Emma's pipeline):

x.flinkMethod(new Foo{})

Instead of completely removing this implicit argument at the start of Emma's pipeline, maybe I could just replace it with a dummy argument like this:

x.flinkMethod((???): Foo)

And then Emma would pass such trees to Squid somewhere in the middle of our pipeline.
And later at the end of our pipeline Emma would remove these dummies and re-resolve them.

Do you think this could work?

Note that this workaround would still need Squid to keep the implicit modifiers on the ValDefs, so that we can resolve at the end of our pipeline.

from squid.

@ggevay Sure, that should work fine. You can name the dummy method:

def inferLater[A](): A = ???

and later transform its applications to:

def inferNow[A](implicit a: A): A = a

from squid.

Good idea, thanks!

from squid.