Just want to give my 2 cents and say that I really like the accum block, it forces me to explicitly scope and declare the “mutable” variables upfront, and make it really clear where its happening. On top of that a tool like Credo could be configured to emit warnings when the block is too complex or big (to be fair any other of the proposed solutions could be checked by Credo, but I think that the accum block feels more “natural”).
rmoretto
marcandre
I strongly dislike that we need to write the name of the variable differently. There is nothing intrinsically different to the variable itself. We just want a different assignment that says “don’t create a new variable in a local scope, but instead rebind the outer scope one”.
For example I can think of code that needs to be refactored, and suddenly a particular variable needs to be reassigned this way. We then have to change all existing instances of my_var and change them to @@my_var? I strongly dislike that idea. Or if we no longer needs to rebind a variable this way, then we suddenly should rename all @@my_var to my_var (would the compiler warn otherwise?).
I’m in favor of a special operator like <~. The fact that there is no way to specify this for pattern match shouldn’t make this a no-go. We can always pattern match on a temporary variable, and then my_var <~ my_temporary_var if need be.
lurodrigo
I’m strongly in favor of current proposal and think this one is the best proposal among the other many similar, but I’d also favor any other proposal attacking the same problem.
I work with nested structures every day and one of the main pains I have is having to write nested reducers, which adds nesting levels, pollutes everything. Naming the reducers/splitting in functions just adds indirection. The code doesn’t get any better bc the accumulation we’re doing usually doesn’t have any name more natural than maybe_add_value_to_acc. If you’re doing this over two or more levels of nesting, you’ll need two artificial names like this.
Another problem the proposal solves is when you have multiple accumulators, you need to be passing a tuple of 3, possibly more elements everywhere, even when often you need to update just one of them. Instead of placing the emphasis on the only accumulator being updated, I need to bother naming each of them in the tuple. This creates some maintenance problems. If you need to change the structure of an accumulator, or add another one, it’s very easy to introduce errors since the language is dynamically typed. If you’re doing, say reduce_while, errors may go unnoticed until a less common case appears.
All these examples could be easily solved with the current proposal. It helps writing this sort of code with way less boilerprate and without adding anonymous or named functions that only introduce noise to the code and don’t help with clarity.
18
Kurisu
Maybe you should update the initial post of this proposal thread with this, for the newcomers? I think this seems to suit most of the speakers in this discussion.
I’m also all for it as well, if it counts. ^^
tfwright
I would counter that if your argument is that this would be mainly useful for a specific niche then you have argued against adding new syntax and for solving the problem in a library.
I also don’t believe I’ve seen any arguments in this thread that wouldn’t be “pragmatic.” Pragmatism is about favoring methods/solutions that have been proven to work vs ones that conform with a systematic vision. I think the problem is clear the only debate (it seems to me) is whether the solution would be practically beneficial enough to justify the addition to the API.
sodapopcan
This is a really good take. I certainly don’t have to write nested reducers daily so ya, I haven’t felt that pain (for context I lean on the side of disliking the proposal though I do really like the block idea). As a bit of a side note (ie, not meant as a rebuttal to your feedback) when I do end up in nested reducers, I very much lean into Elixir being a LISP 2 and keep the same names going down. It’s probably an unpopular choice, but this avoids having to come up with throwaway names and it’s not nearly as confusing as I initially thought it would be when I first started trying it out. YMMV, of course. Again, I don’t write nearly as many as you do.
I think José is leaning away from @@ based on a comment I’m too lazy to scroll up to find. I feel you on this but I would also say in opposition that not having some sort of special syntax hurts scannability. If there is a bunch of code long enough that refactoring out this syntax would be a pain, then having syntax to call these special bindings out is a huge help when reading unfamiliar code very quickly. I’m very much in support of the block solution without any form of special syntax. My thought there is that people are far less likely to write very long blocks, but of course it’s still possible, but it at least keeps the definition of these bindings in one spot.
Actually, that just made me think… would the hypothetical accum blocks be nestable??
nico.t
First of all, thanks Jose for asking the community.
I haven’t really felt the need for such proposal and if you need less code, there’s always the solution of using the process dictionary (even if it’s a bad habit).
The introduction of “with” to refactor error handling was for me a much more useful feature and it’s no surprise the equivalent has been added later in erlang.
I’m not fond of the initial proposal. Although it’s elegant, I fear like others that people will abuse it and write @@my_var everywhere, even for variables that are not actually used as local accumulators.
I prefer the accum block solution as well.
ducharmemp
As a relative newcomer to the elixir community, I support the block based approach as well since it maps more to the macro definitions of for and if, but I can’t help but feel like the expressiveness of each approach is flawed.
In the @@ case, it looks like a module attribute, as a beginner I mentally mapped @ “this is most effective at constants because I see this all the time with constant string values or constant integer values” (see phx.gen.auth for my first real exposure). I understand now what the difference would be, but I didn’t personally see @ and think accumulating values, I think that behavior is mostly only relevant in macro definitions or dsls?
For the block scope, it’s definitely a bit more of what I’d expect for elixir but then you’d hit the case perhaps described better by others, where it’s not obvious that this name behaves differently. Might be misunderstanding the internals of the block but if it’s what I think it is, which is that the name passed into the block can be rebound at will, then that would not be ideal because of the inconsistency I believe it might introduce, there’s nothing more complicated while learning than something is special cased.
While I hung up my js hat a while ago and it’s been a bit of a slog to read through all the threads, I can’t help but think that let better communicates the semantics that are required here, which is that a value is bound to a name and can be rebound at will. Now obviously that opens up a can of worms such as scoping rules and “why do I have let but no const” but just thought I’d throw my small bit of opinion in there.
sodapopcan
let expressions are common in functional languages and they don’t allow for rebinding (at least none of the ones I’m familiar with do), so JavaScript shouldn’t really be looked to for compression here. And of course, the whole beauty of Elixir is that all bindings are constant. It would be better to compare to Rust where let is immutable but let mut is mutable, in Elixir’s hypothetical case we could say that let is just mut in an otherwise keywordless declaration… uhhhhhhhhh, I’m starting to confuse myself. Hopefully we just don’t use let 
Especially because we now have :let in heex which has nothing to do with “immutability.”
connorlay
Similar to @jeregrine, I am strongly in favor of adding local accumulators to Elixir as described here, but I have one question: would it be possible to emit a compilation warning when using local accumulators that are never reassigned? That way developers new to Elixir (or local accumulators) would receive guidance for when they don’t need to add the leading @@ to their variables.