The block solution is my preferred. Looks cleaner and it’s more obvious what is going on.
/chefs kiss
greven
marciol
I liked the idea, but what about make it more general and call it let instead of accum, in a way that allows the same mechanism in a specific closed scope. I know that this resembles a closure mechanism, that would be useful in several ways, not only when using comprehensions.
EDIT:
There is an old proposal that seems to go in the same direction, but why not just make it more general, it would be useful and really explicit because any reference to that scoped variables outside a let block would be caught by Elixir compiler.
christhekeele
Another option for a new syntax construct occurs to me, if (as this proposal seems to be uniquely focused on) you want to define local accumulators for any block. We could add to the family of special keywords do/end supports like else/catch/rescue/finally, say, acc.
This provides little value in the simplest if use-case, where you may as well use the else instead, but perhaps is nicer for complex cases and the for use-case.
else in with and catch in try/def already have precedence for accepting clauses and matching variables with ->. Perhaps we could accept clauses with the generator <- to indicate “generating” out into the external scope. So:
sum = 0
list =
for element <- [1, 2, 3] do
sum = element + sum
element * 2
acc
sum <- sum
end
list #=> [2, 4, 6]
sum #=> 6
This syntax says to me “after evaluating this block (however many times, each time for for) update the binding of the variable sum with the current value of sum, either before returning or iterating again.”
It allows for providing multiple reassignments with mulitple clauses, and doing other intermediate manipulations. Say,
i = 0
list = for element <- [1, 2, 3] do
element * i
acc
i <- i + 1
end
list #=> [0, 2, 6]
i #=> 3 (or 2?)
As others have pointed out before, while this functionality can be used to accumulate, especially if we’re adding it to other blocks than for, it really is just a rebinding tool. So perhaps rebind is a better keyword?
i = 0
list = for element <- [1, 2, 3] do
element * i
rebind
i <- i + 1
end
list #=> [0, 2, 6]
i #=> 3 (or 2?)
christhekeele
Under this construct, the original if example would become:
value = 123
if true do
value = 456
rebind
value <- value
end
value #=> 456
Not a verbosity or readability win, but a trivial case. With a more complicated conditional I can see resurfacing an intermediate value you don’t want to lose or return directly from the expression being useful.
The problem you are trying to address becomes:
section_counter = 0
lesson_counter = 0
for section <- sections do
if section["reset_lesson_position"] do
lesson_counter = 0
rebind
lesson_counter <- lesson_counter
end
section_counter = section_counter + 1
lessons =
for lesson <- section["lessons"] do
lesson_counter = lesson_counter + 1
Map.put(lesson, "position", lesson_counter)
rebind
lesson_counter <- lesson_counter
end
section
|> Map.put("lessons", lessons)
|> Map.put("position", section_counter)
rebind
lesson_counter <- lesson_counter
section_counter <- section_counter
end
christhekeele
Additionally, there is precedence for these do extensions not being allowed on just any block; for else is only allowed in if and with; catch in def and try; so we could pick and chose which block constructs this makes sense for (for and with being the obvious candidates).
VictorGaiva
All the exemples that use a custom keyword to define a variable doesn’t really feels like the it is Elixir. But so far mut keyword felt the best, and we can declare and use Rust mut variables in a similar way, while temporaraly borrowring them to inner scopes.
But now I like this one the best. It feels like it fits very well with the current way Elixir looks and feels, while limiting the area of effect and introducing no additional keyword used to only to declare a variable.
But I feel like this solution might be too limiting, but also Elixir itself already have some similar limites that make a lot of sense.
christhekeele
Notice the question in the comment: i #=> 3 (or 2?)
It suggests two interesting questions about this implementation:
- Would the rebind run again after the final iteration?
- Would not re-referencing
iafter theforissue aunused variablewarning?
The latter point seems compelling to me: if you’re not using the output rebinding, you probably shouldn’t be using the syntax at all! for Enum.with_index/for reduce: being a better alternative.
christhekeele
More idiomatically, I’d want to rewrite this as
section_counter = 0
lesson_counter = 0
for section <- sections do
lesson_counter = if section["reset_lesson_position"], do: 0, else: lesson_counter
lessons =
for lesson <- section["lessons"] do
Map.put(lesson, "position", lesson_counter)
rebind
lesson_counter <- lesson_counter + 1
end
section
|> Map.put("lessons", lessons)
|> Map.put("position", section_counter)
rebind
lesson_counter <- lesson_counter
section_counter <- section_counter + 1
end
But as this is effectively a do-while, it offsets the counts by 1 less. However we can’t initialize the starting values to 1 because then we’d appear to have counted 1 lesson if sections is empty. Not a perfectly elegant replacement, you’d have to do more special-casing before entering the loop.
sabiwara
Elixir Core Team
The point about catch / rescue is a great one, seems like an implementation headache.
Accessing a local accumulator in these would need to be forbidden for this to work I suppose.
(Sorry just thinking aloud) Maybe a separate improvement to comprehensions could be a new break function which could be added and would allow the comprehension to bail. break could support these local accumulators and would allow things usually done with Enum.find_value & co
