After I overslept with the problem, I decided to comment on it again.
Here is the pure comprehension solution, verbose
for {map, map_idx} <- Enum.with_index(input, 1), reduce: {1, []} do
{idx, result} ->
idx = if map["reset_lesson_position"], do: 1, else: idx
{idx, lessons} =
for lesson <- map["lessons"], reduce: {idx, []} do
{idx, acc} -> {idx + 1, [Map.put(lesson, "position", idx) | acc]}
end
map = map |> Map.put("position", map_idx) |> Map.put("lessons", Enum.reverse(lessons))
{idx, result ++ [map]} # to avoid `Enum.reverse/1`
end
This is not easily generalizable (unlike iteraptor’s solution I mentioned above,) but it solves the exact problem stated. It’s readable by anyone familiar with Elixir and it is arguably more succinct compared to map_reduce/3, although it uses the same approach.
Would I personally write this in the production code? Nope. I’d do it with (
) Enum.chunk_by/2.
iex(1)> Enum.chunk_by(input, & &1["reset_lesson_position"])
[
[
%{
"lessons" => [%{"name" => "Welcome"}, %{"name" => "Installation"}],
"reset_lesson_position" => false,
"title" => "Getting started"
},
%{
"lessons" => [
%{"name" => "Addition / Subtraction"},
%{"name" => "Multiplication / Division"}
],
"reset_lesson_position" => false,
"title" => "Basic operator"
}
],
[
%{
"lessons" => [%{"name" => "Mutability"}, %{"name" => "Immutability"}],
"reset_lesson_position" => true,
"title" => "Advanced topics"
}
]
Then it’s a matter of Enum.with_index/2.
I am positive (this is a not humble opinion 
) that every case should be attempted in the way suggested by its shape. Semi-mutability which is not a mutability but rather a syntactic sugar, is not a silver bullet. This particular example, as shown above, might be solved more elegantly. Another example might ring a bell, but this one does not.
As an author of some libraries, I sometimes have a feeling that hey, I should add something cute to it, and I do, and I always regret it. I could not respect more your vision of what is good for the language/ecosystem, and what’s not, @josevalim, but I think you are falling into a trap here. Local semi-mutability which is not a mutability but rather a syntactic sugar cannot even be named properly without confusing readers.
It’s not something that would help newcomers (IMHO) because of “ok, there is some mutability, they say, let me try with what I am familiar to” in many cases when the pure functional solution fits better.
It’s not something that would impress gray-bearded alchemists, because we know how to do it better without breaking the paradigm.
The question “who is the main audience” is widely open. It’s not an ad-hoc, the proposed solution with double-at already is a backward-incompatible change.
That all said, I am fine with whatever José thinks about it, because in my experience he is usually right and I am not (that’s the 102% fact.) But at the moment my personal opinion is we need more examples to convince the audience this is a good addition that brings more value than it blurs the boundaries of the paradigm we all are accustomed to.
