Cannot agree more 
mat-hek
Membrane Core Team
Aetherus
Just imagine that @@xxx is being reassigned all over the place! No lexical scope restriction! I already feel like I’m writing JavaScript 
3
hubertlepicki
I am sorry, I am not a fan of this proposal, for several reasons.
Two reasons make it inconsistent with what we currently have:
- it’s got a different scope than normal variables
- it’s an actual mutable state rather than an immutable variable being renamed/redefined
But also, Elixir got big. It doesn’t have to be a big programming language, it doesn’t have to be Ruby. Clearly, it’s already bigger than Lisp or Erlang or Smalltalk, but being bigger and having more syntax makes it harder to learn, and harder to understand. We’re entering Python territory here and that’s not a compliment.
So that’s my biggest concern, the additional syntax, and overall growth of syntax and quirks and features of the language. At the end of the day, it’s function calls + AST-based macro system that makes Elixir great, and none of the additions, not even comprehensions are strictly speaking necessary.
20
michallepicki
The functional and immutable nature of Elixir grew on me and I appreciate how it lowers the mental overhead of working with code, even if it means the code needs to be a bit more verbose. But I agree that mutability makes some algorithms more concise, like shown in the Problem Statement.
I am curious, will this be implemented as syntax sugar for using the process dictionary?
0
josevalim
Creator of Elixir
Folks, let’s please be more constructive and more respectful of other ecosystems. Yes, getting bigger is a concern, but I am sure we can formulate this in better ways.
It is also worth pointing out that in the last 5 years, there were only two changes to the language itself: stepped ranges and multi-letter sigils. We can go further back but I don’t think we will find much more. So I am not sure I agree the language is getting bigger by any meaningful rate. This proposal has a big impact though and would likely be the biggest change to the language since the introduction of with (roughly 7 or 8 years ago?).
It actually isn’t mutable state. Think of it as a more implicit version of the pipe operator where data is threaded in more complex ways. It doesn’t take away from your other concerns, but we should be clear it isn’t actually mutable.
No, it is based on source code transformation, all code is still pure/immutable.
9
hubertlepicki
I haven’t said anything disrespectful (or didn’t mean to) and it’s criticism of the size of the syntax is constructive and pretty specific by the way. Also: Python is growing like crazy in usage, despite that explosion of syntax, so there’s that to refute my claim of hurting adoption. Objectively, Python’s core syntax it grew a lot, if you had a gap of 15 years in programming Python it’s barely recognizable.
1
Aetherus
What I’m concerning about is that whenever there’s a hole in a system, there will always be someone to leverage that, and there always will be others following that first guy. I fear if there’s a hole in the immutable system, and it’s very easy to leverage, the situation will get out of control.
By the way, I’m the guy who leverages the process dictionary to do dynamic programming 
I don’t know if I’m the first.
2
l3nz
So they are, ahem, global? sounds like a huge gunfoot to me. A cure that’s worse than the disease.
If you copy and paste it wrong, you get a previous/different result that’s out of code scope but is in module? maybe they could be function or scope-prefixed so they cannot be mixed up.
1
josevalim
Creator of Elixir
No, they are local to the scope they are defined, as the name suggests. Think about it like this: a variable in Elixir can be written in its current scope and read on all inner scopes, but not read or written by its parents. Local accumulators can be read and written by the current and inner scopes (but not its parents).
My point is that a defmodule is also a scope, as you can define variables in it (and local accumulators) in it:
defmodule Foo do
barbaz = 123
end
7
mudasobwa
Creator of Cure
Since you’ve closed the previous discussion and my library was kinda mentioned there, here is the solution with Iteraptor.
Mix.install([:iteraptor])
Iteraptor.map_reduce(input, %{lesson: 1, top: 1}, fn
{k, %{"reset_lesson_position" => reset?} = v}, counters ->
{{k, Map.put(v, "position", counters.top)},
%{top: counters.top + 1, lesson: if(reset?, do: 1, else: counters.lesson)}}
{[_, "lessons", _] = k, v}, counters ->
{{k, Map.put(v, "position", counters.lesson)}, %{counters | lesson: counters.lesson + 1}}
{k, v}, counters ->
{{k, v}, counters}
end, yield: :all)
Please note, that this solution might be easily extended to be generic, i. e. not dependent on any depth/parameter name save for the one resetting positions.
I’m not advocating the use of iteraptor though 
It has its flaws. I indeed advocate a Kernel.update_reduce_in/3, accepting the function of arity 2 as the third parameter. It won’t solve the issue out of the box, but one get_in/2 in advance and Enum.zip/2ing the outcome to the input would do (and the complexity would not change even though we are to iterate the list twice.)
7