Sam Sussman

Compiling all functions/closures in the code base will be necessary for step 3.i where we may need integrations given as arguments for `bind`. That is the only real use of...

With no other changes, that would mean we would explore the tree as AST, wiring any integrations starting from the function closure. We'd then us ethe closure serializer to pull...

Which steps could we get rid of? 8 and 9 may be able to be merged, but are fairly minor.

Its possible we can avoid the nativeExpr rewrite because of the changes to the serializer. When we find an integration call, we can return the `integration.native.call` however, the serializer couldn't...

We are essentially doing what you suggest for bind now, but using the typescript AST instead of the functionless AST. Which currently is easier as it involves following complex references...

I still don't think we have a clean solve for replacing the integration call with the `native.call`. ```ts () => { func() // func.native.call() func.functionArn; // leave as is table.getItem()...

Well we were going to add an inline call to be able to invoke the actual closure for testing and other purposes, that would also need the default location. And...

```ts const testMe = func() // "inline", call the closure new Function(async () => { func() // call, use the client to call the lambda }) ```

We can remove things that are safe to always remove, but we'll never get to the same level as if only the `call` is left. The closure serializer discovers runtime...

Another option is to apply the nativeExpr logic to all closures like the proposal with the AST and then the serializer will give us those instances at runtime. ```ts const...