As I see it, doing this via the process dictionary is not “implementing this”. A key part of the proposal is that it would be syntactic sugar over normal immutable operations. Solving it with actual mutability is a significant difference.
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
tmbb
Ok, so that part is important to you. Ok, in that case my solution is defiinitely unacceptable. Also, my solutino also deviates regarding this:
I my implementation, the code above works:
def factorial_with_map(n) do
mutable! result: 1 do
# Update the product inside a map function
Enum.map(1..n, fn i -> result <<~ result * i end)
# Return the mutable variable
result
end
end
and in my opinion it should work. If we want mutable variables, then they better be real mutable variables instead of a very artificial thing that works in for loops and not in map functions. But that is just my personal opinion, of course.
2
tfwright
Personally, having made the transition to thinking in functional terms, I no longer ever wish I could “borrow” the mutable style just to make a some code more readable. Instead I reach for other refactoring tools, clearer variables, breaking out into helper functions etc. I think if ‘local mutability’ like this existed I would just not use it and argue for style guidelines in my projects to avoid it because in some cases I think it’s better to just not even have to make the choice (both when writing and interpreting code). But I have been called a curmudgeon so…
…that said, I like the @@ var syntax, especially in light of how attributes can accumulate, as others have observed.
4
gregvaughn
I’m doing my best to help that! 
I’m coming to this thread late, but I’m glad I read to the bottom before posting since the process dictionary has already been mentioned. Given that we already can implement the desired code with pdict, the concern here is to only appear to be mutable while actually outputting immutable beam code. I’m not convinced the value is worth the cost.
The value is to be more readable in those circumstances which can use the syntax, which doesn’t seem very often. The cost is one more special case to consider. I’ve been with Elixir since beta, so learning one more thing incrementally is not a problem, but it is one more barrier to newcomers.
3
josevalim
Creator of Elixir
Thank you. These points convinced me that @@ is a very sensible prefix in case we want to go ahead with this proposal. The “a” in @ (“at”) also matches the “a” in accumulator (as it matches the “a” in attributes). I think I have all of the pieces in place to submit a new proposal, so I will do that later. Thank you.
4
christhekeele
As you pursue this, I’d be interested in seeing an analysis of how @@var would contrast with existing @var semantics:
-
Assignment
Module attributes assign via
@var value. It looks like accumulating attributes will use@@var = value, is this a vector for confusion? -
Assignment scoping
Module attributes are (usually) assigned to in module bodies. It looks like accumulating attributes are intended to be scoped to function bodies. What will the devex be like if you try to define or assign them them at the module level? Is there a vector for confusion there? Is there a sensible functionality for them at that level, like an accumulation useful in
@on_defcallbacks? Would that sensible functionality cause more confusion if implemented?
1
tmbb
I don’t think it’s a good prefix at all! Currently, the “syntax” @@x is valid and parses into this:
iex(1)> quote do @@a end
{:@, [context: Elixir, imports: [{1, Kernel}]],
[
{:@, [context: Elixir, imports: [{1, Kernel}]],
[{:a, [context: Elixir], Elixir}]}
]}
So it wouldn’t be “real syntax” (I understand that “real syntax” is not something that’s easy to apply to a language like Elixir), it would be just applying @ to a module attribute (not exactly, I know that @ can be rewritten into eveyrthing, but still, the point stands). Wouldn’t it be better to represent mutability by using an “arrow operator” (such as <~ or <<~ for example) and leaving the variable name as it is?
0
christhekeele
It’d be real syntax with a trivial change in the parser to introduce a new high-precedence operator.
It parses into AST, but that AST cannot be evaluated anywhere in a program without raising an error, so is not currently valid syntax.
1
tmbb
With the caveat that what follows depends on your definition of “syntax” (which is quite flexible in how the concept is used in Elixir), @@x is definitely valid syntax and can be incorporated into real programs!
defmodule DarkKernel.StupidAtTest do
use ExUnit.Case, async: true
import Kernel, except: [@: 1]
defmacro @(_arg) do
quote do
"STUPID"
end
end
test "stupid result is stupid" do
a = 1
# Stupid is stupid
assert @a == "STUPID"
# More stupid doesn't actually make it more stupid
assert @@a == "STUPID"
# Even more stupid, but still the same
assert @@@a == "STUPID"
end
end
Turning @@x into a new operator could work, but it would definitely be a backward-incompatible change.
3