Re-assign enclosing object properties to local vals.

[aalexandrov]

Code bracketed with parallelize is normalized as a first step of the compiler chain.

As part of the normalization

• read references to properties of the enclosing class should be assigned to local vars (resolved via 04032bd);
• write references to properties of the enclosing class (e.g. u) should be prohibited (resolved via [MACROS] Issue 84: Semantic checks for unstable applications in enclo… #141)
• references to methods of the enclosing class (e.g. g) should be prohibited (resolved via [MACROS] Issue 84: Semantic checks for unstable applications in enclo… #141)

For example, in the following code example the "parallelized" code accesses k.

class KMeans(val k) {

  def g(x: Int): Int = x + 42

  var u = 0

  def run() = {
    val alg = emma.parallelize {
      val z = f(k) // OK as f is not a local method
      val w = g(k) // not OK as g is local method
      // ...
      xs.map(x => { /* ... */; u = u + 1; /* ... */ } // not OK as u is local state
    }
  } 
}

As part of the normalization, the code should be rewritten as:

      val __this$k = k
      val z = f(__this$k)
      // ...

[joroKr21]

What is the difference between a read / write property of the class and a method? In Scala those are one and the same. Isn't it possible to inline those instead of renaming them?

[aalexandrov]

I think that in the following class

class Foo {
  val Int x = 0
  def x: Int = x
}

The first member is a property and the second a method. Regarding inlining, I am not sure whether you can get hold on the method definition from the macro context in order to do the inlining. Moreover, using methods (like the x getter) inside UDFs in systems like Flink and Spark might be problematic if the enclosing object is not serializable.

I would therefore restrict the use of enclosing object methods in the first step and focus only on the properties.

[joroKr21]

I meant inlining their value, but I guess we don't know it at compile time. My point is that at the call site we cannot distinguish between vals, vars and defs with no arguments, as they are all represented as Selects in the AST. To do that you would have to access the enclosing class definition, which I guess is possible, but goes against the principles of locality.

On the other hand, why restrict access to no-argument methods, when they shouldn't have side effects anyway? At the same time it's easy enough to prohibit calls to methods with arguments.

[aalexandrov]

You can lookup the exact type of a select (val, var, def) through its symbol.

[joroKr21]

Yes indeed, I still have a lot to learn about the Scala reflection API. You can just use isStable then.

[aalexandrov]

Didn't know about that method, good hint!

[joroKr21]

@ParkL I just realized that it doesn't matter if you get Outer.this.x = 42 or Outer.this.x_=(42) in the macro since calling a method of the enclosing class should also be prohibited unless it isStable.

[ParkL]

@joroKr21 Will do! Thanks for the advice! I'm new to the whole thing so all help is greatly appreciated :) I guess there's even more cases to think about ...

Andreas and I just found out one more thing that's weird (at least to me), but it may be a hint at the underlying problem: If I paste my test-quasiquote (with the assignment) into the scala console it renders as expected with an Assign. If I set a breakpoint at doSemanticChecks(e.tree) and run the test in debug mode, inspecting e.tree yields the weird Apply structure. So something is happening to the tree "in between".

If this rings a bell, please let me know. Anyway I'll be looking into this on Monday! Have a nice weekend!

[aalexandrov]

@ParkL This might be something for the scala macros mailing list / JIRA.

[joroKr21]

What happens in between is typechecking that resolves the assignment to the compiler-generated setter x_=. To see this effect in the REPL:

import scala.reflect.runtime.universe._
import scala.reflect.runtime.currentMirror
import scala.tools.reflect.ToolBox
val tb = currentMirror.mkToolBox()
val code = q"class Outer { var x = 1; class Inner { x = 2 } }"
showCode(code)
showCode(tb.typecheck(code))

In contrast method- or block-local vars remain assignments, which I guess is why they differentiate between these cases.

[joroKr21]

Resolved via 04032bd and #141