Relevance of comptime for Winglang

[Chriscbr]

Mitchell Hashimoto recently published an excellent write-up showing how "comptime", a feature of the Zig programming language, can be used for conditionally enabling or disabling code on different plaforms: https://mitchellh.com/writing/zig-comptime-conditional-disable. This feature is important for Zig's target audience, as Zig can be used for writing cross-platform system libraries and low-level applications, as not all hardware and operating systems provide the same APIs and system calls, so only valid code must be compiled for the code to be properly link etc.

Zig's approach is particularly impressive since it folds seamlessly into the language design -- there's no need for separate syntax or preprocessor steps like one might have to do in C.

I believe a feature of this nature may also be relevant for Winglang. In Wing, inflight functions are designed to be bundled and executed remotely after your app is deployed, typically within containers or serverless execution environments like AWS Lambda and Cloudflare Workers. But it's often the case that you may want certain branches of inflight code to only be included if you are compiling the app for production, or for testing, or for the local simulator, or for deployment in a particular environment (like an air-gapped region).

Today, it's possible to conditionally execute code based on compile-time information in Wing by checking at runtime whether some flag or value has been set, and proceeding accordingly:

bring cloud;
bring util;

// this environment variable is automatically set by the Wing compiler
// to a value like "sim" or "tf-aws" or "tf-azure" etc.
let target = util.env("WING_TARGET");

let bucket = new cloud.Bucket();
new cloud.Function(inflight () => {
  if target == "sim" {
    log("I'm running in the simulator!");
    bucket.put("key", "value1");
  } else {
    log("I'm running on the cloud!");
    bucket.put("key", "value2");
  };
});

However, this approach isn't ideal since code from both branches of the "if" statement (and any code they reference) will be included in the final generated code. This can be problematic since importing individual modules and libraries can have significant performance costs, especially if they introduce side effects.

Wing's platform system ameliorates this by providing an contract whereby classes can be conditionally injected based on the compiler platform. For example, in the code above, cloud.Bucket has separate AWS and Azure implementations, so code generated when the app is compiled to the tf-aws platform will not include the Azure SDK, and code generated when he app is compiled to the tf-azure platform will not include the AWS SDK. However, this is still limiting since all dispatching is solely based on the "platform" flag. Furthermore, in order to perform this kind of conditional code inclusion, the inflight logic must be refactored into a dedicated class.

This proposal is related (it proposes some syntax that would allow inflight functions to have metadata associated with them that can be parsed and used to alter how the resulting code is bundled or deployed), but it doesn't appear to address the dead-code elimination use case I've mentioned above.

Open question: How could we allow branches of inflight code to be conditionally included or excluded based on preflight-evaluated information without significantly increasing compiler complexity or the mental overhead for users? Is it possible to do something clever through esbuild or related plugins?

[MarkMcCulloh]

The holy grail here imo is that preflight expressions and control flow can be executed/evaluated by the time inflights are bundled.

so, in a case like

let target = util.env("WING_TARGET");

let bucket = new cloud.Bucket();
new cloud.Function(inflight () => {
  if target == "sim" {
    log("I'm running in the simulator!");
    bucket.put("key", "value1");
  } else {
    log("I'm running on the cloud!");
    bucket.put("key", "value2");
  };
});

if target == "sim" should somehow become if(true) or at least if("sim" == "sim") by the time esbuild runs. In which case, esbuild can do the minification work to do dead-code elimination.
I'm not sure how this would be implemented, there are definitely some hurdles in the way for this to "just work".

Right now lifts are passed to inflights via an argument, e.g.

// main.w
let x = true;
new cloud.Function(inflight () => {
  if x {
    console.log(true);
  } else {
    console.log(false);
  }
});

results in

// preflight.cjs
// ...
const x = true;
// ...
static _toInflightType() {
  return `
    require("${$helpers.normalPath(__dirname)}/inflight.$Closure1-1.cjs")({
      $x: ${$stdlib.core.liftObject(x)},
    })
  `;
}
// ...


// inflight.$Closure1-1.cjs
"use strict";
const $helpers = require("@winglang/sdk/lib/helpers");
const $macros = require("@winglang/sdk/lib/macros");
module.exports = function({ $Util, $x }) {
  class $Closure1 {
    constructor($args) {
      const {  } = $args;
      const $obj = (...args) => this.handle(...args);
      Object.setPrototypeOf($obj, this);
      return $obj;
    }
    async handle() {
      if($x) { console.log(true) } else { console.log(false) }
    }
  }
  return $Closure1;
}
//# sourceMappingURL=inflight.$Closure1-1.cjs.map

Because the inflight module is a function with arguments, it can't be minified. This is silly specifically for x because it is immutable, so the value could not possibly be anything else.

There needs to be a different system for injecting lifted values that is more static-friendly.
We could generate a unique token for each lift and inject it right before bundling