All good! 
Eiji
billylanchantin
With the understanding that this is adding “local accumulators” instead of general mutability, I’m for this! I think I’m not alone in wishing I didn’t have to create ad hoc tuples in order to accumulate multiple values.
All I want to say is that I think a different syntax is crucial. I’m going to try to circumvent the moratorium on syntax by saying that I don’t care what it is so long as it’s different. If x = x + 1 can change a value of x even outside it’s current scope, I’d like to know just by looking at it!
As others have said, F# has this. And they have a special syntax for reassigning mutable variables:
let mutable x = 1
x <- x + 1
If Elixir gains this power, I think you should have to opt into it with syntax. Otherwise, accidental mutation accumulation will happen.
6
dimitarvp
Cool, that’s good then. Thank you for reminding me, and sorry about not addressing it in my comment.
In this case I believe you should aim for specialized syntax for this particular scenario and not introduce something that can and will be misinterpreted as general mutability (albeit with a limited scope). People come to Elixir already expecting stuff they are used to, so let’s not exacerbate this problem.
I like @bit4bit’s idea the most: let’s have for option that provides special treatment of the variables listed in it (including nested for blocks). Whether it’s called state or accumulators or mutable or iterables (or iterators) remains to be discussed but IMO you should stick to this thing being a specialized syntax sugar to make using for more intuitive.
EDIT: Though if you plan on this being used not only in for constructs then yes, your original idea seems the most reasonable, with some syntax amendments to avoid ambiguity.
0
fuelen
The concept is interesting. It is cool to get ideas from experimental languages. However, I’m sceptical about adding this to Elixir now, since it won’t bring performance benefits. I already see a new credo rule for blocking local mutability, because this is readability only issue 
I almost didn’t work with mutable languages during the past 5 years, so I don’t even think in a way “I need mutability here, since it is more readable”. When I have an opportunity to write some JS code, I write it using functional style even if it takes more lines (usually it doesn’t). This is easier for me. Let’s think about the opposite - how will the code look like if mutability is overused? Will we have a new anti pattern page in docs?
I may be wrong, but introducing mutability opens another topic - arrays.
4
josevalim
Creator of Elixir
Thanks everyone for your inputs. I will close this proposal soon and resubmit it without mentioning mutability. There are two aspects to decide:
-
What should we call them? Local state? Local accumulators?
-
We definitely need explicit syntax to declare them, such as the
mut“keyword”, do we also need explicit syntax to reassign them? I am personally undecided. F# does use a different syntax, as @billylanchantin mentioned, but in F# it is literally mutable and it crosses the local scope, which is why you need a different syntax. One of the reasons to not have different syntax is: what if you write{foo, bar} = some_fun()wherefoois a mutable (as in this proposal) butbaris not? Using a separate operator would not capture this nuance. Using a sigil such as$foois an alternative but it has a much bigger footprint on the language. Anyway, we don’t need to decide this now, but it is food for thought.
I’d say only here is a red herring, readability is extremely important and it should be enough reason.
7
sabiwara
Elixir Core Team
- What should we call them? Local state? Local accumulators?
Since this is a different scoping rule for variables (we can already re-assign them, just not in a nested scope), how about something with “scope” like “local scoped variables”?
- We definitely need explicit syntax to declare them, do we also need explicit syntax to reassign them?
I wondered the same, especially from the point of view of metaprogramming or static analysis: would having a separate operator help distinguish at the AST level or shouldn’t this matter?
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I rewrote your earlier example using $foo just to sort of see what it looked like and a few things caught my eye:
let $section_counter = 0
let $lesson_counter = 0
for section <- sections do
if section["reset_lesson_position"] do
$lesson_counter = 0
end
$section_counter = $section_counter + 1
lessons =
for lesson <- section["lessons"] do
$lesson_counter = $lesson_counter + 1
Map.put(lesson, "position", $lesson_counter)
end
section
|> Map.put("lessons", lessons)
|> Map.put("position", $section_counter)
end
One very noticeable change is that it’s immediately more apparent where in the code the “local accumulators” are being accessed and modified, and I think this is sort of a plus. They operate differently from normal values but they are necessarily intermingled with regular values, and you can tell at a glance you’re dealing with one of these “special” variables without having to go trace up to where it was defined.
The other bit that became clear though is that I think we still need to keep the let or similar up front binding to establish where the scope for it lives.
I don’t have a strong opinion about $ vs some other signifier. $ does seem somewhat fitting though.
12
adw632
The reduce form of comprehensions allows carrying the necessary state, is it just a matter of education on the idioms?
{sections, _, _} =
for section <- sections, reduce: {[], 1, 1} do
{acc, section_position, lesson_position} ->
lesson_position = if section["reset_lesson_position"], do: 1, else: lesson_position
{lessons, lesson_position} =
for lesson <- section["lessons"], reduce: {[], lesson_position} do
{acc, lesson_position} ->
lesson = Map.put(lesson, "position", lesson_position)
{[lesson | acc], lesson_position + 1}
end
section = Map.put(section, "position", section_position)
{[%{section | "lessons" => Enum.reverse(lessons) } | acc], section_position+1, lesson_position}
end
sections = Enum.reverse(sections)
0
dimitarvp
This has been covered the first time such proposal was discussed. It’s not a skill issue, it’s a readability issue. I personally don’t mind Enum.map_reduce and using tuples that carry multiple accumulators but I’ll agree with the others that this can become unwieldy and hard to read, pretty quickly.
I’ve solved this for myself by devising a special accumulator struct – or simply use a map so the combined accumulator’s goals are more apparent (since, you know, a struct / map has named keys) – but I understand if people would just prefer some mutable[-like] syntax to make the whole thing easier to read and maybe it having less coding lines (debatable).
Another way I am keeping complexity at bay in these cases is to liberally use small private functions with descriptive (usually long) names.
5
dimitarvp
This definitely looks better but I fear that somewhere in the near future we might really need the dollar sign for something else (say, the upcoming type checker) and it will be taken.
Though that makes me wonder… how many free special symbols Elixir still has at its disposal for future syntax additions? And I mean only those in the English alphabet and the QWERTY keyboards, not the entirety of Unicode.
1