Constant/variable shadowing

[gustavopch]

What?

Civet:

response := await fetch(...)
body := await response.json()
shop := body.shop
log response.status

response := await fetch(...)
body := await response.json()
products := body.products
log response.status

Output:

const response = await fetch(...)
const body = await response.json()
const shop = body.shop
console.log(response.status)

const response2 = await fetch(...) // Suffixed with `2` because another `const` with the same name already exists
const shop2 = body2.json()
const products = body2.products
console.log(response2.status)

Why?

• Naming is hard.
• Temporary variables may not deserve a unique name. They're not worth the risk of bikeshedding.
• It's only for consts. In the end, you'll really be creating different variables. Much better/safer than reassigning/mutating a let variable.

Relevant links

• https://rescript-lang.org/docs/manual/latest/let-binding#binding-shadowing: ReScript has this feature and this page explains it well.

[edemaine]

I think the one potential downside to this is "safety". Someone might use const/:= and really want the variable to always mean that thing, and prevent shadowing in the same way that const prevents reassignment.

But I think the benefits are generally stronger here. It just may be good to keep an option like "civet -constShadowing" that turns this off, for those who want regular ECMAScript behavior (and it should be part of "civet jsCompat").

[edemaine]

Another option for compilation that we've discussed is adding braced blocks, like this output:

const response = await fetch(...)
const body = await response.json()
const shop = body.shop
console.log(response.status)

{
const response = await fetch(...)
const shop = body.json()
const products = body.products
console.log(response.status)
}

(or maybe one braced block for each overriding const declaration)

The nice thing here is that we don't have to rename used variables (which might be an issue e.g. when writing the object literal {response}; don't want the property to get a name of response2).

Ideally we'd be able to support getting values from the previous scope. For example, consider this input:

i := 0
process i
i := i + 1
process i

With variable renaming as in the original post, this is straightforward to compile: the third line becomes const i2 = i + 1. With braced blocks, we can still compile this and achieve minimal renaming as follows:

const i = 0
process(i)
const i2 = i  // give the current value of i another name
{
const i = i2
process(i)
}

It occurs to me that this might have some weird interaction with garbage collection, as the i2 value sticks around potentially longer than i — if i is let not const. In this case, we might want to use a WeakRef, which I believe is safe because it's assigned immediately before it's dereferenced:

let i = 0
process(i)
const i2 = new WeakRef(i)
{
const i = i2.deref()
process(i)
}

[gustavopch]

Oh, good point about { response } Vs. { response2 }!