Accessing reassignable variables from inflight

[Chriscbr]

I've started to wonder whether it could make sense to support a way to reference reassignable variables defined in preflight from inflight scopes. That's a lot of jargon so let's see what that means...

Recall that today, Wing prevents you from using a reassignable variable inflight if it was declared in preflight. The main function of this is to prevent you from writing programs that try to mutate some kind of shared state where no shared state exists:

bring cloud;

let var count = 5;

new cloud.Function(inflight () => {
  count = count + 1;
  log(count);
}) as "fn1";

new cloud.Function(inflight () => {
  count = count + 2;
  log(count);
}) as "fn2";

Wing makes this a compile error because to most readers, it looks like the count variable tracks a value, and that functions in the cloud may be able to increment it as they please. But if we were to compile this today (bypassing the error), what we'd find is that the value of count would get inlined into the code of fn1 and fn2, so that when they were invoked, they would get executed with count initialized to 5 (and any changes would be forgotten after the functions complete). That's not what most users expect, so the compiler currently raises this as an error. (To solve this in Wing, you could use a cloud.Counter resource instead of a plain num instead).

But suppose we only access the variable without reassigning to it:

bring cloud;

let var count = 5;
count = 10; // OK

new cloud.Function(inflight () => {
  log(count); // no reassignment
});

count = 15; // OK

Despite the initial ambiguity of the value of count, it's possible to define a simple rule for how this kind of variable access could work across all wing programs -- inside inflight scopes, reassignable variables always take on the last value that they had during preflight. In this case, the last value taken on by count during preflight is 15, so 15 would be logged by the cloud.Function.

Under the hood, the cloud.Function code would use a "token" value to represent count, so the function code can be bundled without knowing what the value of count is yet. This kind of mechanism is already used today by the SDK whenever you access an AWS resource like an AWS Bucket or Queue. Before deploying your app, we don't know what the physical resource name in your AWS account will be, so a "token" or placeholder is inserted into your bundled code, and the placeholder is filled in at runtime using an environment variable.

Here's a longer example showing how this might be used in some real-world code:

bring cloud;

resource PrefilledBucket {
  var base_size: num = 0;
  inner: cloud.Bucket;
  init() {
    this.base_size = 0;
    this.inner = new cloud.Bucket();
  }
  add_picture(key: str, data: str) {
    this.inner.add_object(key, data);
    this.base_size = this.base_size + 1;
  }
  inflight check_pictures() {
    let var count = 0;
    for key in this.inner.list() {
      this.inner.get(key);
      count = count + 1;
    }
    // Here we reference `this.base_size` which is a reassignable variable, but
    // we know that it is not reassigned, so the compiler can prove that this
    // access is safe.
    if count < this.base_size {
      throw("only ${count} images found, was the data tampered?");
    }
  }
}

let b = new PrefilledBucket();
b.add_picture("flower", "sunflower.jpg");

new cloud.Function(inflight () => {
  b.check_pictures();
}) as "test";

Limitations

The above example may be reasonable when the reassignable variable is a num, but what if it's another kind of capturable type, like a resource? Take the following snippet:

bring cloud;

let var b = new cloud.Bucket(); // here is a reassignable variable with type `cloud.Bucket`

resource A {
  init() {}
  inflight handle() {
    b.put("key", "value"); // here the reassignable variable is used inflight
  }
}

let a = new A();
new cloud.Function(inflight () => {
  a.handle(); // this cloud function needs to be granted IAM permissions to the bucket defined at the end of the file (!)
});

b = new cloud.Bucket() as "replacement";

Even though the final value of b is known to be resolved once all preflight code is executed, the fact that b changes means it is unclear what binding information should be added to A so that when a.handle() is called, it is granted IAM permissions to access the bucket.

I would propose to to restrict this capability initially to simple types. By "simple types", I mean capturable types that do not include resources. For example, str, num, Array<str>, Set<str>, enums, simple structs, and so on. (Or alternatively, just any type that can be converted into Json).

[ekeren]

Another way to put this is saying that reassignable variables inflight capturing mechanism creates a non-reassignable version of them. (and then we need to think if it makes sense to the mut/imut primitives as well

@Chriscbr, How would you achieve the above result with the current type system?

[Chriscbr]

Another way to put this is saying that reassignable variables inflight capturing mechanism creates a non-reassignable version of them.

Exactly, you explained it better than I could 👏

(and then we need to think if it makes sense to the mut/imut primitives as well)

I had mutable collections on my mind as well, but I didn't want to over-complicate the proposal. 😅

@Chriscbr, How would you achieve the above result with the current type system?

I think for simple types(*) the implementation might be straightforward - whenever we are type checking, the compiler can tell whether the current scope is preflight or inflight, and it has information about whether variables are reassignable are not, so tweaking how we analyze captures might not require a lot of work.

(*) I've added a new "Limitation" section to the proposal explaining why this might be harder if the reassignable variable refers to a resource or an array of resources etc.