Editors can help with readability without adding extra syntax to the variable. Rider adds an underline for mutable variables in F#
cmo
adw632
I have re-read the past thread with the let proposal. What I proposed is not the same, the major difference being the variables bound in let need to be returned as the tuple from the block.
I didn’t have a problem with for let but I didn’t like that proposal because the return tuple from the comprehension is not connected to the let binding in the next round in an obvious or intuitive way. Needing to provide a result tuple with the results ordered in a particular way and the usage of let didn’t convey mutation/rebinding on each iteration. It would be better conveyed with say var instead of let.
I am suggesting similarly declaring the state in the comprehension (let’s not worry about syntax for now) but automatically using whatever value they bind to for the next “iteration”. If that state is also to be returned as a result of the comprehension (i.e. binding to variables in the parent scope), it similarly will take the current binding of whatever the comprehension set or left them at.
This way the comprehension state is continuously being reused and rebound as needed each iteration without manual effort to explicitly return it. It’s basically like mut within the comprehension and some way to return this state to the outer scope at the end which is not part of the for map/reduce result. You could return a tuple containing the result and the state (not as obvious IMO) or provide some other way to express the binding between the comprehension state values and the parent scope.
0
josevalim
Creator of Elixir
This was certainly discussed at some point, so perhaps it was in a past-past proposal or in a branched thread?
In any case, it is worth pointing out that tying it to comprehensions in your example is purely a syntactic restriction. The implementation complexity would be pretty much the same and anyone could get the same behaviour as this proposal by doing:
for _ <- 1..1, ^session_counter, ^lesson_counter do
for lesson <- lessons do
...
end
end
So tying it to comprehensions only makes the comprehensions feel more bloated (beyond generators, filters, into, and reduce), which was one of the main concerns before, and less likely to be used.
0
lud
I fear that the mental model for the code execution will be suddenly way harder because I can see less experienced developers (at least reagarding FP patterns) abusing those mutable variables because they think in a mutable way by default.
And it will be hard to argue with them that the code is a mess because yes, there is more whitespace delimitations, less state carrying, etc. So obviously the code is easier to understand.
Except it’s not. Now whenever you have a 15-lines functions you will have to constantly check if the variable is mutable whenever you see =. A different operator or assignment form has limitations, (cannot mix mut and regular variables in assignment) but at least it would limit those problems.
I fear there will be many cases of assignment where the semantics would not be clear:
mut x = 10
x =
case {:a, 1} do
{:a, x} -> x + 1
{:b, x} -> x * 2
end
Or the compiler will forbid a lot of stuff and get in the way.
So I would say no to that. But I like the proposal anyway, I’m glad this would be possible in Elixir with some compiler magic.
I feel that the first step towards the section/lesson problem should be smaller. For insance turn this:
vars = []
vars = if opts[:foo], do: [{:foo, get_foo()} | vars], else: vars
vars = if opts[:bar], do: [{:bar, get_bar()} | vars], else: vars
into this:
vars = []
vars ^= if opts[:foo], do: [{:foo, get_foo()} | vars]
vars ^= if opts[:bar], do: [{:bar, get_bar()} | vars]
2
adw632
I do take your point that it’s a lot of special tratment for a single construct rather than a broader language capability.
Comprehensions do appear to have something about them that, pardon my pun, “reduces” their use in actual code vs other idioms.
I can certainly see where comprehensions are useful for flattening the processing with multiple generators. My feeling is that comprehensions don’t compose with pipelines so we just use Enum or Stream which does.
Perhaps an Enum.for that works similar to for where the generator input goes on the left and can have additional generators and state would cross the cavern, but I’m just hypothesizing.
0
thomasbrus
- What should we call them? Local state? Local accumulators?
Calling them local accumulators makes the concept a lot easier to understand imho.
It fits the reason for proposing this feature in the first place (to locally accumulate some values).
The moment state or mutability is mentioned it gets confusing. Since you can also keep track of state in Elixir via processes. And as you mentioned the compiled code is still immutable.
8
bit4bit
Ok, now i understand that it’s about not losing the possibility of using the “accumulators” in all the mechanisms that comprehensions offers. However, opening the accumulators outside of the comprehensions seems to open the door to new (or old) strange code
I am sure i will start reading code like
let $flag = false
if $flag == false do
$flag = true
end
....nested block...
$flag = false
and lost the restrictions that allows to think in a different way.
what about a new kind of comprehensions, maybe forlet or some other that limits the scope of accumulators only to the concept of comprehensions?
2
thiagomajesk
Yes! Separating the concept from plain variables is imperative and it makes a lot of sense… In this case, I think the possible @@ syntax mentioned by @josevalim would fit the mental model very well. IMHO because we already use @ to define attributes (which can be used somewhat like compile-time accumulators) it makes the mental jump a lot easier and avoids confusion.
I must say that I like this version a lot..
@@list = []
if some_value? do
@@list = ["prefix" | list]
end
And I find its explicitness very appealing…
@@section_counter = 0
@@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
5
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I completely agree with this as well. I think it also helps the mental model around “what happens when I pass this to a function”? In both @ and @@ the answer is the same: you just get a regular value. They aren’t defining special values, just special syntax. From the perspective of a called function everything is as normal.
2
tmbb
Why cannot solve this “problem” using some macro magic?
It’s actually easy to do this withing a scoped block using macros defined in a 140-line file. I’ve uploaded a gist here: dark_mutable.ex · GitHub (I can’t push it to the main github repo because right now I’m on a network that doesn’t suppor SSH).
You can see it being used in a simple factorial function (note that mutable assignment is done using the <<~ operator; I don’t think that mutable variables should be assigned with the = operator, even though it’s very easy to implement it):
defmodule DarkKernel.DarkMutableTest do
use ExUnit.Case, async: true
import DarkKernel.DarkMutable
def factorial(n) do
# Define a mutable variable, which is only accessible inside the block
mutable! result: 1 do
for i <- 1..n do
# Update the variable in a way that's propagaded "up" the AST scopes
# in the entire `mutable!` block.
result <<~ result * i
end
# Return the "mutable variable"
result
end
end
test "factorial function works" do
assert factorial(1) == 1
assert factorial(2) == 2
assert factorial(3) == 6
assert factorial(4) == 24
assert factorial(5) == 120
end
end
This generates the following code:
18:07:07.305 [debug] test/dark_kernel/dark_mutable_test.exs:7
┌────────────────────────────────────────────────────────────────────────────────────────────────────
│ ⤷ Code:
├╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶
│ for i <- 1..n do
│ DarkKernel.DarkMutable.__set__(result, DarkKernel.DarkMutable.__get__(result) * i)
│ end
│
│ DarkKernel.DarkMutable.__get__(result)
├────────────────────────────────────────────────────────────────────────────────────────────────────
│ ⤷ Generated code:
├╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶╶
│ result = make_ref()
│
│ try do
│ DarkKernel.DarkMutable.__set__(result, 1)
│
│ (
│ for i <- 1..n do
│ DarkKernel.DarkMutable.__set__(result, DarkKernel.DarkMutable.__get__(result) * i)
│ end
│
│ DarkKernel.DarkMutable.__get__(result)
│ )
│ after
│ DarkKernel.DarkMutable.__delete__(result)
│ end
├────────────────────────────────────────────────────────────────────────────────────────────────────
The code above doesn’t generate the
@josevalim, given that I have implemented this in about 1h30min, I don’t think major language changes are needed, and I don’t see much use for the mut keyword.
I’d even argue that having the variables scoped inside a clearly delimited block is a much simpler solution. And this implementation automatically gaurantees that external processes can’t change the references, because there isn’t a way of sending the reference somewhere else. Reference values are always passed by copy.
4