Overshadowing variables should not be allowed

[matiwinnetou]

The following Aiken code will compile:

fn hello_world() {
  let a: Int = 0
  let a: Bool = True

  a
}

I believe this could should not compile and the compiler should complain that variable a is already defined in the scope.

[rvcas]

The underlying UPLC also supports shadowing natively it's safe to let it happen, and it's pretty useful sometimes. I think this kind of thing can be up to personal preference, if you don't want to shadow you don't have to.

[rvcas]

Rust has shadowing, plenty of languages do. It's pretty common.

As far as the javascript comment, I'm not exactly sure what you mean. You can shadow variables defined with let. Here's an example you can try in your browser console.

[matiwinnetou]

That's pure madness for me. I would love to hear other opinions here (@KtorZ , @MicroProofs , @alessandrokonrad ? ) and I certainly don't want to take JavaScript as an example how one should develop smart contract language.

[KtorZ]

I believe shadowing is fine in some situations, and even actually better than the alternative. Take the following example:

let sum = list.foldr([1,2,3,4], fn(n, sum) { n + sum }, 0)

sum on the outer let-binding is actually shadowed by sum in the anonymous function argument. Reading this however, it is clear how both are connected and, it makes it clear that the final sum you get was constructed iteratively through the fold. Without shadowing, one would have to use different names. This is a pretty common useful use case.

Now, there are situations where I agree that name shadowing can be confusing and be error-prone. In particular, when the variables live under the same scope. So this for example:

  let a: Int = 0
  let a: Bool = True

is completely ill-advised IMO. Yet, rather than forbidding this in the compiler, I'd rather include this as part of a static-analyzer / linter rules and identify this particular case, as well as potential others, as dangerous -- while still allowing legitimate use cases like the one I showed above. This really falls under the responsibilities of a linter, and not so much of the compiler in my opinion. Alternatively, we could, like in Haskell have an optional warning message for that. Though we don't have ways of turning warning off at the moment, so it could be pretty annoying.

[matiwinnetou]

I see, thank you for your explanation and reasoning, highly appreciated.

[matiwinnetou]

For the example you gave above in Scala I have been using what is known as accumulator pattern since in Scala it is not possible / advised to do shadowing of variables (same in Java, one gets a compilation error).

https://stackoverflow.com/questions/47007747/functional-way-to-map-over-a-list-with-an-accumulator-in-scala

Accumulator pattern expects that one introduces a new variable for the accumulated value. In the example that you showed it is indeed useful and this extra variable can seem weird but is also more explicit which sometimes can be a good thing.