Add binding keyword that prohibits shadowing / rebinding: val foo = "bar"

[inoas]

Today when reading gleam-lang compiler Rust code I've encountered a binding that seemed to appear directly below in an interpolated string that was sprintf'ed. I was pretty confused at first why one can interpolate a non string variable. Then I realized the binding was shadowed.

I think readability and explicitness could be improved by adding a binding keyword that prohibits rebinding like be, final, or fin or val.

let a = "I want to be rebound!"
fin b = "Don't touch me!"
val c = "Don't touch me!"

This enhancement would not affect current Gleam usage and allow future library and application developers to make their intentions clear by writing - say - val foo ... instead of let foo ... if their intention is to not rebind and have the compiler warn if they later do let foo ... or val foo ....

Unlike mutateable languages (where I feel const vs final vs val vs var vs let need a deeper understanding on what's going on) there is also no confusion:

• let would signify a variable: binding mutable, value immutable
• val would signify a value: binding immutable, value immutable

[arothuis]

Overall, I'm in favor of this addition as it reduces possible confusion when reading code: let / val reveals the intention of the author to allow rebinding or not. It also might help onboarding people coming from other languages which offer such keyword. It's good that existing projects are not affected (except, perhaps, if val is used as a name).

However, this slightly increases language complexity (one more keyword to know about) and increases project variability: there's no longer 'one way to do things'. See all the (pointless?) debates about let vs const in JavaScript.

[inoas]

Here is an example from the current compiler code, it is not Gleam, but it is where I stumbled over shadowing, and it is what made me make this discussion post:

https://github.com/gleam-lang/gleam/blob/main/compiler-cli/src/export.rs#L62-L82

    // Write entrypoint script
    let entrypoint = out.join("entrypoint.sh");
    let text = include_str!("../templates/erlang-shipment-entrypoint.sh")
        .replace("$PROJECT_NAME_FROM_GLEAM", &package.config.name);
    crate::fs::write(&entrypoint, &text)?;
    crate::fs::make_executable(&entrypoint)?;

    crate::cli::print_exported(&package.config.name);

    println!(
        "
Your Erlang shipment has been generated to {path}.
It can be copied to a compatible server with Erlang installed and run with
the entrypoint.sh script.
    {entrypoint}
",
        path = out.to_string_lossy(),
        entrypoint = entrypoint.to_string_lossy(),
    );

So here entrypoint get's defined, and then it gets run but as part of something that looks like sprintf it gets shadowed. But if read from top to bottom entrypoint must be some form of string, but at the point you read it it clearly is not. This may be more related to the bindings in the function call, but it would not be possible if shadowing would either not be possible or if shadowing would be explicit.

I like the suggested retry/reuse/relet but it is not compatible with existing code bases because then let a followed by let a in the same or a sub scope would need to throw a compile error.

I'd really like const/let in javascript IF const were actually a constant (but it is just a constant binding, not a constant value).

---

I did not think about rebinding via use and try when I suggested to use val or fin in conjunction with let. It makes little sense to me to have a non-rebindable let but not a non-rebindable use and/or try.

IMHO the sensible appraoch would be reuse, relet and retry and forbidding let/use/try to be rebindable. I still think there is a lot of value there because every "variable" is what you declare it to be, even if you read other people's code, and nothing else except when you explicitly and willfully overbind it - imho something that will prohibit some programmer/logic errors and help against confusion with others.

p.s.: Another way would be a compiler flag or a community-built linter that just warns about rebinding, but without constructs like relet and reuse one has to go the erlang way and add indexes for rebindings which is not good.

[lpil]

That println example isn't variable shadowing, and in Gleam we don't have anything like that. I don't think that explains why it might be a problem in Gleam.

[timjs]

I understand your concerns @inoas, but your example is a bit contrived. It's more Rust specific and not general shadowing. I agree with @lpil here.

[inoas]

Yes, I understand.

Generally with a lot of callback nesting shadowing as in tracing what binding to a variable is the one relevant gets worse. I feel use will help somewhat there.

Generally I don't see a path forward except one that is not BC, aka making let not being able to rebind. And while I feel that it should have been that way from the start and relet/reuse/retry are great ideas, introducing it now non-BC isn't great.

Thus for me the proposal ends with that unless there are better ways out (like setting in gleam.toml if shadowing is allowed or not or linters).

[inoas]

Afterthought: Next to let, use and try there would also be case pattern matching which shadows:

pub fn main() {
  let a = 1
  case True {
    a -> a
    _ -> 2
  }
}

And here there would be no easy way to use relet/reuse/retry.

[sporto]

I find shadowing undesirable when working with nested folds. It is very easy to repeat a variable name ending up with unexpected results. e.g.

    list.fold([1,2,3], 0, fn(acc, i) {
        list.fold([4,5,6], acc, fn(acc, i) {
            ...
        })
    })

This is a simple example, but I have made some others (doing advent of code) where it not very obvious that you are making a mistake. In this case I wish the compiler would disallow shadowing. i.e. tell me that I cannot use acc in the nested fold as it is already taken in the outer fold.

[hayleigh-dot-dev]

Shadowing in this manner trips me up regularly in Gleam. It was a source of much head-scratching when implementing yak.

I consider shadowing to be in the same class as mutation in so much as it can be useful, if you have the discipline to use it right, but is so easy to miss/misuse that it's better to just disallow it entirely.

I don't expect @lpil will budge on this one, but throwing my opinion in the ring because it's a common cause of frustration for me when writing Gleam code.

[NthTensor]

Would it be possible to disallow shadowing across blocks? Any time there is a curly brace, all of the higher scope of the closure cannot be rebound. Seems like a nice balance, because then all rebinds must come from let.

[inoas]

I don't feel that this is easier for newbies to understand versus having val (forbids rebinding) as a default and let (requires rebinding) as an alternative (but I could be wrong!).

[NthTensor]

I don’t know. Apart from stuff like example above, when you allow shadowing across blocks you can have situations where a variable seems to “pop” back to a previous state.

let foo = 1
let bar = 6
let baz = {
  let foo = foo * 3
  { foo - 1 } * bar
}
// foo = 1

This is kinda the point of blocks, yes, but I think this can actually be pretty unintuitive to beginners.

[inoas]

Hm, when I read your example I thought you implied the nested block would rebind foo in the outer scope. It does not and I feel that is what I would expect, even as a newbie, as it is in a block, that looks like a function body without arguments, and function bodies never rebind the outer scope anywhere.

But I am not opposed to the change you suggest. I just think val and let may be a bit better. But louis also mentioned that there is no back tracking so in both cases the compiler would require some significant changes AFAIU.

[inoas]

I forgot about case and callback fn args, so for me retry/reuse/relet ain't an option (as there is no way to force a rebind in a case pattern match with those keywords); so that would be back to square one:

1. val could be introduced which prohibits any rebinding through val, let, use, try or case pattern matching. While this may not be perfect in isolation it is something that we can add now that authors can/should use unless they intend to rebind.

2. In case of let being used but no rebinding occuring the compiler could even warn about this (let versus no-rebinding)

3. For Gleam 1.0 or 2.0 could forbid let if there is no rebinding occuring forcing people to use val which could be a way to have:

@timjs: "make the preferred way of working easy, make it more difficult to do advanced things"

... and would result into clear signaling:

If there is a val you know it will not get rebound, if there is a let you know it will get rebound.

[massivefermion]

I don't think this is a good idea. It complicates the language for no good reason. I know some may think this could reduce confusion but I don't think that's true. There are two ways this could be implemented:

1- The distinction between val and let is only a convention that Gleam programmers are supposed to follow. But you can't actually guarantee that everyone follows that convention, so you may actually end up with a good amount of code that declares variables with val but rebinds them later anyway. This would even be more confusing than the current situation, so you just made the problem worse!

2- If someone declares a variable with val but tries to rebind it later, the compiler throws an error. Is this really a good idea? Introducing a compile error to the language just because some programs may confuse other people, even though the developers themselves could very well know what they're doing! I don't think so!

I think till now Gleam has been able to maintain an incredible balance between simplicity and expressiveness and that's actually the main thing I love about it. I don't think the issue presented here is enough of a reason to disturb that simplicity.

[inoas]

While I tripped over shadowing today, I am growing to the idea that it just ain't good to have both concepts. Gleam decided for rebindability and there we are.

[human154]

Another approach, which is not backward compatible would be to have a sigil for variables that are shadowed or shadowable like $var or ~var or something along those lines. That would make it even more explicit that rebinding is taking place for a certain variable.

If someone declares a variable with val but tries to rebind it later, the compiler throws an error. Is this really a good idea? Introducing a compile error to the language just because some programs may confuse other people, even though the developers themselves could very well know what they're doing! I don't think so!

I would emphasize the value of making it easier to read other people's code and I would argue that this should be prioritized. It would be trivial for a developer who knows the code they are writing super well and knows that the language does not permit implicit rebinding (if that were the case) to add a dollar sign when shadowing (and given the simplicity of this, compiler errors are unlikely to be generated, unless you are unwittingly shadowing). Then, as we would have this as a compiler guarantee... for ever after, for all Gleam code, everywhere, it's just a bit easier for people already grappling with the complexities of other people's code to understand it, as the burden of tracking when something may or may not be rebound is on the compiler and not me, and its also made explicit.

I appreciate that many people don't value being explicit about rebinding (not saying that was the intention of the comment above), and even more I realize that there are circumstances were it is quite handy to be able to rebind. But being explicit about rebinding gives the best (more or less) of both worlds, or it's a good compromise between no rebinding and full implicit rebinding. But for me and others who would prefer to have the compiler track that detail over doing it ourselves, having only full implicit rebinding is unfortunate.

I realize this is a trade off in terms of the simplicity of the language, and having a tiny added learning overhead, and there would be a sacrifice in terms of backward compatibility. However, either we make that sacrifice or we sacrifice the advantage we would have of offloading to the compiler the burden of tracking rebinding.

For me, the one time learning of the fact that i need to prefix a shadowing variable with something would by far be worth it if it makes reading all Gleam code everywhere a bit easier for all time.

[lpil]

Gleam strongly aims to have as small a surface area as possible and to not have multiple ways of doing things. To have multiple variable definition syntaxes with slightly different behaviours would not be aligned with those core goals.

[human154]

Ok, as it is, writing and learning Gleam is arguably a bit simpler but reading it is a bit more complex than if shadowing was made explicit, its a tradeoff you get to (/ have to) make and sadly for me, I don't.

Of course I still respect and appreciate the work you are doing.

Just for the record, wanting syntax to make two different things look different (shadowing and assignment) doesn't (I think) violate a principle of not having multiple ways of doing the same thing (although it arguably increases the apparent surface area as you say).

Arguably, in those terms I'm wanting to change that gleam currently does two different things in the same way (shadowing and assignment) and places the burden on the reader to make the distinction. Even if you are making the right choice because the apparent initial simplicity of the language increases adoption etc I still think there is a strong case to make that people who appreciate the benefits of a static type system making life easier for them would appreciate knowing clearly if something with the same name is the same thing or if it could have changed in some intervening code. I would think that people who appreciate Gleam would appreciate that kind of thing. Now that I've done my annual rant on this I can happily go about my business knowing that I've done all i can to express a point that is important to me 😄 . Carry on.

[lpil]

I think it definitely does violate that. Currently assignments always behave the same way- there is no difference between shadowing and assignment. They are the same thing.

If we introduce a different way it goes from one to three behaviours:

• The currently (shadowing and assignments are the same)
• The new, used in a valid sense (not shadowing, a new assignment syntax with new rules to learn)
• The new, used invalidly (shadowing, a new assignment syntax with new rules to learn, new error messages, and a way for the program to fail to compile based upon context from anywhere else in the module).

There is nothing inherently more or less complex about permitting or not permitting shadowing, both have their pitfalls. We have picked one (the only where the programmer needs the least amount of context to understand code, where adding a new module constant cannot result in type errors in unrelated code).

To add a second core language feature for declaring variables cannot avoid both increasing the size of the language, and also making it unclear which variable declaration feature should be used.

[human154]

@lpil Thanks for elaborating on your thinking on this.