Instead of starting with a generator, our comprehension starts with a
let variable = initialexpression.
I think init works better as a “special type of generator”/“generator wrapper”:
for sum <- init(0), x <- [1, 2, 3] do
{x * 2, sum + x}
end
This looks unsurprising to my eye.
I think the reinjection is somewhat implied because of for. But you are right, there is nothing conveying the fact it is updated from the return tuple.
Honestly, the only option so far that conveys this fact is map_reduce:
for map_reduce(sum = 0), x <- [1, 2, 3] do
{x * 2, sum + x}
end
But if we were to call it map_reduce, I would change the tutorial to first introduce reduce, and then introduce map_reduce as a way of getting for to return its value and reduce at the same time.
I still have reservations about calling map_reduce, I am worried it is not immediately clear to those who are initially looking at it, but given we simply cannot agree on a new word, it may be that the best option is to use the vocabulary we already have.
Given a for comprehension has the following pipeline
generation -> filter -> reduction
There are currently two variations
generation -> filter -> map
generation -> filter -> reduce
and this discussion seems to be largely about adding
generation -> filter -> map_reduce
IMHO the existing form describes this pipeline very well:
[2, 4, 6, 8, 10] == for i < [1, 2, 3, 4, 5], is_odd(i), do: i * 2
9 == for i <- [1, 2, 3, 4, 5], is_odd(i), reduce: 0, do
acc -> i + acc
end
Adding support for map_reduce could follow this existing form with:
{[2, 6, 10], 9} == for i <- [1, 2, 3, 4, 5], is_odd(i), map_reduce: 0, do
acc -> {i*2, i + acc}
end
The lesson example would then read as
{sections, _acc} =
for section <- sections, map_reduce: {1, 1} do
{section_counter, lesson_counter} ->
lesson_counter = if section["reset_lesson_position"], do: 1, else: lesson_counter
{lessons, lesson_counter} =
for lesson <- section["lessons"], map_reduce: lesson_counter do
lesson_counter ->
{Map.put(lesson, "position", lesson_counter), lesson_counter + 1}
end
section =
section
|> Map.put("lessons", lessons)
|> Map.put("position", section_counter)
{section, {section_counter + 1, lesson_counter}}
end)
Compared to the proposed form there’s little in it in terms of syntactic noise and to my eye makes it clearer how variables will be bound.
{sections, _acc} =
for let {section_counter, lesson_counter} = {1, 1}, section <- sections do
lesson_counter = if section["reset_lesson_position"], do: 1, else: lesson_counter
{lessons, lesson_counter} =
for let lesson_counter, lesson <- section["lessons"] do
{Map.put(lesson, "position", lesson_counter), lesson_counter + 1}
end
section =
section
|> Map.put("lessons", lessons)
|> Map.put("position", section_counter)
{section, {section_counter + 1, lesson_counter}}
end
Yeah, from the perspective of return type calling it map_reduce is indeed clearer. Although the proposal argues in the last section (and I also linked in the replies above) to why the variables for map_reduce/reduce should be introduced before the generators. 
Oh, I’ve misunderstood the original proposal then. I thought count and sum were being reset. In that situation I would think let ... for ... would be the more obvious syntax but agree with the priority of not requiring new special syntax.
Overall a great proposal.
I have doubts this should be supported.
I imagine those variables will be simple initial values (0, empty list, etc…), so probably their initialization code will not be that big.
The consequence of allowing this is that they are no longer declared and used only within the scope of for_let block.
This could be confusing to users, as somebody could try to use the let variable after the for_loop and could expect the value to be the same as the last one in the loop.
An example:
iex> sum = 0
iex> count = 0
iex> for let {sum, count}, i <- [1, 2, 3] do
...> sum = sum + i
...> count = count + 1
...> {i * 2, {sum, count}}
...> end
{[2, 4, 6], {6, 3}}
iex> sum # What is the value?
0
So I think it may be better if those variables can not be used (including initialized) outside of this block at all.
I doubt there is anything to be done about it, but I will share my impression from reading this block of code the first time.
iex> for let {sum = 0, count = 0}, i <- [1, 2, 3] do
...> sum = sum + i
...> count = count + 1
...> {i * 2, {sum, count}}
...> end
Here let bindings are on the first position in the first line, but they are returned as the second element in the tuple.
So there is this inconsistency and I think for some users it may be not intuitive to figure out which element in the tuple should be first and which second.
I am still not convinced about the name let. On one hand, it is short and communicates what it does. On the other hand, it means different things in other programming languages. I imagine programmers coming to Elixir and being surprised they can declare a variable with let only inside for comprehensions. It also could communicate to some people it can be mutating (let vs const in JavaSript).
Maybe reusing directly the Haskell accum?
init is also interesting, especially if initialization was not allowed outside of the for block.
You have to assign the result of for so you can rebind the original variables or introduce new ones. You have a choice.
That’s a great argument against implicit initialization from outside variables. Explicitly needing to state both the variable name for the accumulator as well as the value or variable for the initial value should be better on that front.
Right so just to make sure I’m on the same page, you’re saying that it should be required to:
sum = 37
{items, sum} = for let sum = sum, ... do
{i, sum}
end
Particularly the sum = sum bit to sort of emphasize the rebinding significance. I think I can get behind that actually.
I’m not really a fan of init. Initializing the value is only one thing that happens, the other is that it is updated to the returned value at each iteration, and init not only doesn’t really tell you that, but it has such an “intuitive” meaning that you’d sort of expect it to only function to set the initial value.