Despite the fact that comprehensions can be used for this problem, the Enum.map_reduce form is still easy to read for those familiar with Elixir (IMO).
It does beg the question if Enum.map_reduce is sufficient ,and reads nicely (as per Jose’s original post), do we really need to change anything?
Do we need a better example problem that is a lot more clumsy to solve without comprehensions and requires “local accumulators” / “function scope rebinding” ?
I feel that the problem with comprehensions is that they have an almost imperative style, which is a more familiar way to those coming from non functional languages, but not to those who have made the mental switch to a functional approach.
The illusion of that imperative style also starts to break down because when using an immutable functional language we can’t do things the same way, and must shift our thinking. I hazard to guess this is why the uptake on comprehensions is low, once you shift your thinking to the functional way it just feels strange to use an imperative looking style, even though for is still built on recursion.
As for the function scope mutability I would never want to use it, and would ensure credo checks to weed out any use of it because it is unnecessary and wreaks of an imperative style.
I would entertain a more constrained form, such as deliberate binding of comprehension state variables from/to the outer scope, and compiler checks to raise an error on any rebinding/assignment to a variable that shadows a variable/binding in the outer scope and which has not been specifically bound to the comprehension state.
I did previously suggest a syntax such as pinning but that would be confusing, a better syntax might be inner <-> outer to indicate the binding goes both into and out of the comprehension.
).
I am not trying to change their mind.