multiple assignment syntax/semantics seem of dubious utility

Consider code like the following:

a = 1
...do_something_with_a...
...do_something_else_with_a...

Assume in this case that the "do_something..." blocks are large and/or complex pieces of code where the use of "a" isn't necessarily immediately obvious. Now a maintenance programmer, fixing a bug, does the following:

a = 1
...do_something_with_a...
a = :foo
...do_something_else_with_a...

Code is now silently breaking because mutating the variable in-place (semantically, not necessarily physically) has just broken the "...do_something_else_with_a..." block. If this block isn't executed frequently it could be some time before the error is spotted.

Now what is bizarre to me is that to prevent this you'd need to do this instead, if I read the specs right:

a = 1
...do_something_with_a...
^a = :foo
...do_something_else_with_a...

You have to explicitly flag "I don't want to modify this variable", the maintenance programmer would actually have to know that there's another use of "a" later on. But if that's the case, there's no need for the ^ tag because the maintenance programmer wouldn't have changed the variable.

To me it would be most obvious to have non-mutability be the default state and that the ^tag is a way of saying "yes, I know I'm changing a previous value". In this way it's like the ! suffix on mutating Scheme functions and the like. The way it is seems, to my eyes, to have absolutely no use whatsoever.

[yrashk]

I would actually be interested to learn the story behind making that decision to make single assignment explicit in Elixir.

[josevalim]

The main reasons for multiple assignment and its current default behavior are convenience of use. In practice, I find more common to assign to the same variable (usually when manipulating a data structure) than to match against it. Also, albeit a bit orthogonal, the explicitness of using ^ when I want to match on an existing variable is really welcome.

However, what worries me the most about this post is its premise: "assume in this case that the blocks are large and/or complex pieces of code where the use of a isn't necessarily immediately obvious".

If you have large or complex pieces of code, assignment is only part of your issues. And we should not design a programming language assuming people will write horrible code (we already know where this leads to).

Finally, it is also worth pointing out that the issue you have describe also happen with Erlang (and in your proposed solution), the difference is that instead of accidentally overriding a variable, you will accidentally match against a variable that was previously set (which may work sometimes but sometimes it won't). Both languages require me to know all the variables in scope every time there is a pattern match. If you don't have tests, both code will have unexpected results in production.