One idea that came to me yesterday was
for binding sum = 0, x <- [1, 2, 3] do
{x * 2, sum + x}
end
It works on 3 levels:
I was thinking bind instead of binding because there is already binding/0/1, so:
for bind sum = 0, x <- [1, 2, 3] do
{x * 2, sum + x}
end
Constructs like for are called special forms, because they have to be implemented by the compiler for optimizations and so on. We only have a few of them. The issue is that you can’t define/import a function with the same name as a special form and the variations would most likely have to be a special form.
I am not convinced binding or bind is any different than let? And only the first proposal was imperative but that has been thrown out of the window by now.
I think the biggest mental blockers to me is that the accumulator is declared in the first term, and the iterator is in the second term, then your output is a tuple with the iteratee as the first term and the accumulator as the second. This feels a bit un-elixirey because in reduce the enumerable/enumerated are both first term and the accumulator is the second term.
Of slightly less concern, but still a bit of a stumbling point for me was that there isn’t some sort of a semantic expectation that a tuple is being restructured as part of the result. Maybe something like this might help:
for {n <- enum, let s = 0} do ...
Don’t know if I love that either.
It reduces a small amount of boilerplate in the original example but I agree it is not significant. My hope though is that it reduces the conceptual overhead of reaching to that solution in the first place.
However, I think there are examples where it reduces considerably. Today, as I worked, I tried to see examples where to apply it. Here are two.
This:
Enum.flat_map_reduce(subs, sources, fn sub, sources ->
sub_formatter = Path.join(sub, ".formatter.exs")
if File.exists?(sub_formatter) do
formatter_opts = eval_file_with_keyword_list(sub_formatter)
{formatter_opts_and_subs, sources} =
eval_deps_and_subdirectories(:in_memory, [sub], formatter_opts, sources)
{[{sub, formatter_opts_and_subs}], sources}
else
{[], sources}
end
end)
Can be rewritten to this:
for let(sources),
sub <- subs,
sub_formatter = Path.join(sub, ".formatter.exs"),
File.exists?(sub_formatter) do
formatter_opts = eval_file_with_keyword_list(sub_formatter)
{formatter_opts_and_subs, sources} =
eval_deps_and_subdirectories(:in_memory, [sub], formatter_opts, sources)
{{sub, formatter_opts_and_subs}, sources}
end
And this:
def find_asset_info(notebook, hash) do
Enum.find_value(notebook.sections, fn section ->
Enum.find_value(section.cells, fn cell ->
is_struct(cell, Cell.Elixir) &&
Enum.find_value(cell.outputs, fn
{:js_static, %{assets: %{hash: ^hash} = assets_info}, _data} -> assets_info
{:js_dynamic, %{assets: %{hash: ^hash} = assets_info}, _pid} -> assets_info
_ -> nil
end)
end)
end)
end
to this:
for reduce(value = nil),
value == nil,
section <- notebook.sections,
%Cell.Elixir{} = cell <- section.cells,
output <- cell.outputs do
case output do
{:js_static, %{assets: %{hash: ^hash} = assets_info}, _data} -> assets_info
{:js_dynamic, %{assets: %{hash: ^hash} = assets_info}, _pid} -> assets_info
_ -> nil
end
end
As soon as you get any kind of nesting, the comprehension format really starts to stand out.
I’m fine with let personally – and I think I understand why it was chosen – but in reading through all of the posts thus far, I saw there was some concern regarding let and some other suggestions etc. In light of that, bind just seemed more Elixirish to me.
I like the abilities that this proposal brings, but let/reduce are a bit of a non-obvious pair to my eyes. map_reduce/reduce seem more obvious, but I believe we’re trying to avoid the introduction of those words. It would be nice to either use a single word for both reduce and map reduce or no word at all. If we were to use a single word, accum makes pretty good sense to me.
So how do we make it such that no (or one) word is necessary? I don’t think this has been mentioned yet and perhaps for good reason … One option might be to let the shape of the return dictate whether it is effectively a reduce or a map reduce. In the case where an accumulator is included, a list must be returned. When the list includes two items it is a map reduce and with one item it is a reduce.
Effectively a map reduce
iex> for sum = 0, i <- [1, 2, 3] do
...> sum = sum + i
...> [i * 2, sum]
...> end
[[2, 4, 6], 6]
Effectively a reduce
iex> for sum = 0, i <- [1, 2, 3] do
...> sum = sum + i
...> [sum]
...> end
[6]
What about set? And what about moving it into the KW list at the end?
for i <- [1, 2, 3], set: sum = 0 do
{i * 2, sum + i}
end
That way if there is already a sum, it would be
sum = 0
for i <- [1, 2, 3], set: sum = sum do
{i * 2, sum + i}
end
Also, as a separate issue, (while consistent since plenty of other things do this in the language) I feel like without any type system implicitly returning the iterator value combined with the sum joined in a tuple is not intuitive. It would be nice to see syntax specifically for this form so that the implementation of it being returned as a tuple is not a common bug new users trip on. Creating a macro something like using(i * 2, sum + i) for the for return value would be best for readability and writability.
What I don’t really like about let is that it’s very specific to assignment. (init is even worse in this regard IMO.) let var = 0 means cause var to become 0, but that’s only the surface of what this qualifier is doing in the proposal. Sure, it causes var to become 0; but then it rebinds var each loop based on the output of the previous one.
for (let x = 0... feels natural in JS, but that is because all the let keyword is doing semantically in that case is actual assignment. In our case, let is actually changing what happens as for generates values, by rebinding certain variables in the block’s scope before it is re-executed.
I guess, calling this qualifier let because it lets variables start off as something… before rebinding them each loop, feels a lot like if Elixir decided to call = the assignment operator, because it assigns to variables… if they were unbound as the end of a very powerful pattern-match feature. let is doing much more here, it deserves a better name! 
I like bind because it means more literally “keep these things close together”, whereas let is a more dismissive, one-time thing. We are not just letting var = 0, we are binding var to 0 and binding the lifetime of var to the execution of the for loop. I guess? It is hard to talk about how words feel in programming…
That’s fair, shouldn’t bring it back into discussion!
I lost track of the message responding to my plug for more of a flat_map_reduce than flat_map, but since I’ve seen early halt come up again: I think my point was that the flat_map_reduce would allow us to put the acc after the generators and filters (which I feel reads more like the rest of Elixir) and still have a mechanism to filter or emit more values within the do end, which for more complicated logic I feel would be clearer than trying to cram it all into generators and filters.
Taking the reduce-as-a-complex-find example:
for reduce(value = nil),
value == nil,
section <- notebook.sections,
%Cell.Elixir{} = cell <- section.cells,
output <- cell.outputs do
case output do
{:js_static, %{assets: %{hash: ^hash} = assets_info}, _data} -> assets_info
{:js_dynamic, %{assets: %{hash: ^hash} = assets_info}, _pid} -> assets_info
_ -> nil
end
end
That would look more like this:
for section <- notebook.sections,
%Cell.Elixir{} = cell <- section.cells,
output <- cell.outputs,
acc: nil do
acc ->
case output do
{:js_static, %{assets: %{hash: ^hash} = assets_info}, _data} -> {:halt, assets_info}
{:js_dynamic, %{assets: %{hash: ^hash} = assets_info}, _pid} -> {:halt, assets_info}
_ -> {[], acc}
end
end
#=> {[], assets_info | nil}
To me that seems easier to see what’s going on.