I’m a big fan of comprehensions, and I love the idea of making them even more useful.
My first impression is that for let and for reduce don’t read like most of the language. Even though the :reduce option is a little strange, matching on the acc reminds me of a case or fn.
Edit: to me it’s not clear that the variables bound in for let and for reduce are repeatedly bound to. I’m not used to seeing that elsewhere in the language (except for the left side of a generator; maybe I’m only okay with that because I’m used to it, but I think the <- operator helps).
for i <- 1..10, reduce: {:even, 0} do
{:even, n} -> {:odd, n + i}
{:odd, n} -> {:even, (n + 1) * i}
end
Edit: to me it’s not clear that the variables bound in for let and for reduce are repeatedly bound to. I’m not used to seeing that elsewhere in the language (except for the left side of a generator; maybe I’m only okay with that because I’m used to it, but I think the <- operator helps).
I think the same. Something like for {sum, count} <- let {0, 0}, i <- my_list, do: ... could be cool too.
Edit: I like it actually because in that case let would be just a thing that implements the ForLoop protocol and not specific
The more I think about it, the more of a curve ball I think for let is, specially for newcomers.
If I read this elixir line:
for let {count, sum} = {0, 0}, i <- [1, 2, 3] do
In plain English I read:
for let count & sum equal to 0, item in elements do
Which is not very descriptive on it’s own, and a little confusing considering the meaning in other languages. Certainly I would never expect it to be basically Enum.map_reduce.
I don’t know the intricacies of Elixir lang, but I would try to make it understandable on a english language level (that’s why the Python version is so understandable in my opinion).
Uninformed & probably silly proposal:
for map_reduce i <- [1, 2, 3], acc: {count, sum} = {0, 0} do
I do, though, like the flat_map-style interface. I wonder if an option to do more of a flat_map_reduce-style interface would cover most of these cases. You could conditionally emit zero, one, or many output values for every generator value or even halt iteration. I don’t think it’s that big a deal to throw out some part of an acc (or the collection paired with the acc, in this case).
I’m picturing something like this:
{results, acc} =
for value <- my_enumerable(), acc: @initial_acc do
acc ->
case do_something_with(value, acc) do
{:one, result} ->
{[result], update_acc(result, acc)}
{:many, results} ->
{results, Enum.reduce(results, acc, &update_acc/2)}
:ignore ->
{[], acc}
:error ->
{:halt, acc}
end
end
I agree that this makes the comprehension “read” oddly in English. What about this kind of qualifier syntax:
for i <- [1,2,3,4],
let {count, sum} = {0, 0} do
sum = sum + i
count = count + 1
{i, {sum, count}}
end
Now in English it’s more obvious what this parses out to: “For every item in the list let variables count and sum be zero and do the following functions using the item, count, and sum.”
Actually, as an implementation detail this might be the simplest as behind the scenes the let keyword just wraps the initial assignment in an enumerable: let {count, sum} = {0,0} being equivalent to {count, sum} <- [{0,0}]
To me the let word carries the imperative / mutable connotation still. Has it been considered that using e.g. acc and not let might be steering the reader into the right way of thinking about this new for syntax?
I like this, a lot, and here let actually makes more sense (to me at least).
In a comprehension, the flattening happens by supporting multiple generators. I don’t think we need to introduce another way of flattening, especially because the way comprehensions currently flatten also allow you to filter easily. And this adds an even bigger departure from the regular for (as in the most common case we now need to wrap each of the collection’s element in a list).
The proposal also explains why it is beneficial to have the variables declared before the generators, as it gives us more power to express other constructs later on.
I strongly disagree with this version. If I were to read such code, I would expect count and sum to be reset on every new value of i.
To be honest, I would say “having to read perfectly in english” is a red herring. I understand the current syntax can be confusing for some (and there is criticism saying so), but optimizing for “english readability” is not what we should aim for to address it.
The proposal also explains why it is beneficial to declare the “let” variables early on, as that gives the ability to express more complex scenarios in the future.
The proposal explains why it is important for the variables to be declared at the beginning, instead of at the end, but I also want to discuss the point you bring about map_reduce.
In my mind, “for” already means “map”, because that’s what it does by default. So “for map_reduce” is, in a way, the equivalent to “map map_reduce”. Also, I am worried that “map_reduce” doesn’t mean much for someone who doesn’t know what it means (but perhaps that should not be a reason to not use it). Other words that we considered were using for reduce instead of for let and for reduce_only to mean only reducing.
My first thought was actually to call it for with, to mean I want to do a for with these variables, but that would be ultimately very confusing with the with special form. I also considered for using, to mean I want to do a for using these variables. However, given the way to introduce variables in many imperative and functional languages is via let, that’s where we landed at the end. We also considered for given.
acc is functional jargon and an abbreviation. We could call it accumulate but maybe that’s too long? We could consider synonyms to accumulate too, such as gather and collect:
iex> for accumulate(sum = 0), i <- [1, 2, 3] do
...> sum = sum + i
...> {i * 2, sum}
...> end
iex> for gather(sum = 0), i <- [1, 2, 3] do
...> sum = sum + i
...> {i * 2, sum}
...> end
Then the follow up question is: would for accumulate and for reduce be clear enough to say which one is a map_reduce and which one is a reduce?
Also see above in this reply for a discussion on the names considered so far.
EDIT: Oh, Haskell calls it mapAccum instead of mapFold/mapReduce…
and not specific 
If I were to read such code, I would expect count and sum to be reset on every new value of