9 ms·

I only have some familiarity with Erlang, Does anyone know the rational behind not being able to change a variable's value? Is it simply historical? It seems y

by zephjc 17y ago

I only have some familiarity with Erlang, Does anyone know the rational behind not being able to change a variable's value? Is it simply historical? It seems you have to call f() to 'forget' a variable before assigning a new value to it - what a maddening name for a built-in function ;-)

tmountain 17y ago
The rationale behind immutable (a.k.a. unchangeable) variables is rooted in Erlang being designed as a concurrent functional programming language from the bottom up. Whenever you have multiple operations manipulating a single value, you're immediately responsible for synchronizing access to that value and ensuring it always exists in a consistent state. Rather than deal with the complexities of synchronization, some languages opt to make all their data immutable and encourage the programmer to write code in a functional style. The fact that the f() function seems unintuitive is because that's not how code is written in Erlang. f() is merely a convenience function for unbinding a value from the Erlang shell, and it is not used in the real world. Rather, you setup initial bindings and then use recursive functions to yield new values as needed. This requires a shift in your thinking about programming, but it offers huge advantages when working within a concurrent model. For more info on the dangers of mutable state in concurrent systems, I suggest the following article: http://www.artima.com/articles/hickey_on_time.html http://www.artima.com/articles/hickey_on_time.html
- KevinMS 17y ago
  I've done some programming in Erlang and I found the immutable variables to be a total pain in the ass that gave no benefit. Your code ends up littered with var=1 var2=var+1 type idioms. Also, the immutable variable have nothing to do with concurrency. Since threads cant touch each others data, and they can only talk to each other through messages, immutability only applies to a local scope, where its really no big deal. Last time I checked somebody was making a scripting language built on top of the erlang runtime and he says that immutable variables are nonsense.
  - iamaleksey 17y ago
    If your code ends up littered with Var2 = Var1 + 1 type "idioms", then you are probably doing it wrong. I hardly ever write code like that (or see other's Erlang code like that). It's by no means an idiom.
    - KevinMS 17y ago
      From programming erlang by Joe Armstrong: At this point you might be wondering how it’s possible to program with- out variables. How can you express something like X = X + 1 in Erlang? The answer is easy. Invent a new variable whose name hasn’t been used before (say X1), and write X1 = X + 1. X=#todo{}. X1 = #todo{status=urgent, text="Fix errata in book"}. X2 = X1#todo{status=done}. From Armstrongs thesis X = 5; X1 = X + 10; I found those just by searching on "X1". There are more X1 examples in the erlang otp sources. Who knows what else is in there.
      - iamaleksey 17y ago
        I'm not saying this never happens. It does, but you'll rarely see this pattern in any real Erlang code base. And when you see it, it will not be "littered". It's an exception, not an idiom. And those samples from Joe's book and thesis are just snippets with no context. BTW, O'Reilly's "Erlang Programming" doesn't even provide such an example. Edit: One example when I do use this pattern is constructing proplists for some function calls.
        silentbicycle 17y ago
        Erlang's style was very strongly influenced by Prolog, and in Prolog code, it's quite common to see e.g. "X1 = X + 1", but having X2, X3, etc. as well is rare - there's usually not a succession of modified versions of a variable in the same function (clause), because it's a sign that you could break things up better. The same is true in Erlang - code with several such variables is written with a strong Java accent (or whatever), not in idiomatic Erlang.
    - artsrc 17y ago
- silentbicycle 17y ago
  While I fully agree that the immutability-by-default mindset helps with concurrency, having single-assignment variables within the local scope of functions (what zephj is complaining about) is strictly due to Erlang being originally implemented in Prolog. Strictly speaking, letting you destructively modify local variables in Erlang wouldn't have any impact on concurrency. In Prolog, it's because there's only unification, not assignment. Semantically, it's as if "X always had that value, it just wasn't known until now" - you can pass around unbound values and retroactively bind them for all places of use, but you can't ever change them. (Difference lists are probably the best example of this in action.)
  - tmountain 17y ago
    Ok, I didn't make the distinction regarding local function scope. Clojure distinguishes these types of values as "transients", and yes, they definitely provide value in regard to both convenience and performance.
- tlrobinson 17y ago
  Isn't it also somewhat important for pattern matching?
frognibble 17y ago
Variable bindings in Erlang are immutable to support the pattern matching. If variable bindings were not immutable, then Erlang would need syntax to distinguish between free and fixed variables in a pattern. The "=" in Erlang is pattern match, not assignment. Erlang could make bindings mutable without impacting the concurrent nature of Erlang because values would still be immutable.
- xtho 17y ago
  It nevertheless is confusing for somebody who doesn't know erlang. Even prolog uses different symbols for matching a variable and for defining a clause.
  - gloob 17y ago
    And Turkish is confusing for someone who doesn't know Turkish. If you want to use a language, learn it.
    - xtho 17y ago
      An explanation for this digression from prolog syntax would have been welcome.
- rvirding 17y ago
  It is as you say, you must make a choice, trying to have both becomes very confusing. In LFE (Lisp Flavoured Erlang) I went the other and added proper scoping. It is the lack of scoping which I consider to be the most confusing and has caused some strange features. Having mutable variables is definitely possible but I don't really see the problems with immutable ones. You get used to it very quickly.
tb 17y ago
f() is only available in the Erlang shell/REPL. The reason it has such a short name is that it's intended for use in the shell and not in real code. Its purpose is for forgetting a variable name that you may have defined earlier during interactive testing in the shell. It's not available in compiled code and is not intended for re-assigning variables within a function.
Herring 17y ago
Functional Programming For The Rest of Us -- http://www.defmacro.org/ramblings/fp.html http://www.defmacro.org/ramblings/fp.html What works for me is thinking of fp as describing mathematical relationships instead of changing state

by zephjc 17y ago

tmountain 17y ago

The rationale behind immutable (a.k.a. unchangeable) variables is rooted in Erlang being designed as a concurrent functional programming language from the bottom up. Whenever you have multiple operations manipulating a single value, you're immediately responsible for synchronizing access to that value and ensuring it always exists in a consistent state. Rather than deal with the complexities of synchronization, some languages opt to make all their data immutable and encourage the programmer to write code in a functional style. The fact that the f() function seems unintuitive is because that's not how code is written in Erlang. f() is merely a convenience function for unbinding a value from the Erlang shell, and it is not used in the real world. Rather, you setup initial bindings and then use recursive functions to yield new values as needed. This requires a shift in your thinking about programming, but it offers huge advantages when working within a concurrent model. For more info on the dangers of mutable state in concurrent systems, I suggest the following article: http://www.artima.com/articles/hickey_on_time.html http://www.artima.com/articles/hickey_on_time.html

KevinMS 17y ago
I've done some programming in Erlang and I found the immutable variables to be a total pain in the ass that gave no benefit. Your code ends up littered with var=1 var2=var+1 type idioms. Also, the immutable variable have nothing to do with concurrency. Since threads cant touch each others data, and they can only talk to each other through messages, immutability only applies to a local scope, where its really no big deal. Last time I checked somebody was making a scripting language built on top of the erlang runtime and he says that immutable variables are nonsense.
- iamaleksey 17y ago
  If your code ends up littered with Var2 = Var1 + 1 type "idioms", then you are probably doing it wrong. I hardly ever write code like that (or see other's Erlang code like that). It's by no means an idiom.
  - KevinMS 17y ago
    From programming erlang by Joe Armstrong: At this point you might be wondering how it’s possible to program with- out variables. How can you express something like X = X + 1 in Erlang? The answer is easy. Invent a new variable whose name hasn’t been used before (say X1), and write X1 = X + 1. X=#todo{}. X1 = #todo{status=urgent, text="Fix errata in book"}. X2 = X1#todo{status=done}. From Armstrongs thesis X = 5; X1 = X + 10; I found those just by searching on "X1". There are more X1 examples in the erlang otp sources. Who knows what else is in there.
    - iamaleksey 17y ago
      I'm not saying this never happens. It does, but you'll rarely see this pattern in any real Erlang code base. And when you see it, it will not be "littered". It's an exception, not an idiom. And those samples from Joe's book and thesis are just snippets with no context. BTW, O'Reilly's "Erlang Programming" doesn't even provide such an example. Edit: One example when I do use this pattern is constructing proplists for some function calls.
      - silentbicycle 17y ago
        Erlang's style was very strongly influenced by Prolog, and in Prolog code, it's quite common to see e.g. "X1 = X + 1", but having X2, X3, etc. as well is rare - there's usually not a succession of modified versions of a variable in the same function (clause), because it's a sign that you could break things up better. The same is true in Erlang - code with several such variables is written with a strong Java accent (or whatever), not in idiomatic Erlang.
  - artsrc 17y ago
silentbicycle 17y ago
While I fully agree that the immutability-by-default mindset helps with concurrency, having single-assignment variables within the local scope of functions (what zephj is complaining about) is strictly due to Erlang being originally implemented in Prolog. Strictly speaking, letting you destructively modify local variables in Erlang wouldn't have any impact on concurrency. In Prolog, it's because there's only unification, not assignment. Semantically, it's as if "X always had that value, it just wasn't known until now" - you can pass around unbound values and retroactively bind them for all places of use, but you can't ever change them. (Difference lists are probably the best example of this in action.)
- tmountain 17y ago
  Ok, I didn't make the distinction regarding local function scope. Clojure distinguishes these types of values as "transients", and yes, they definitely provide value in regard to both convenience and performance.
tlrobinson 17y ago
Isn't it also somewhat important for pattern matching?

frognibble 17y ago

Variable bindings in Erlang are immutable to support the pattern matching. If variable bindings were not immutable, then Erlang would need syntax to distinguish between free and fixed variables in a pattern. The "=" in Erlang is pattern match, not assignment. Erlang could make bindings mutable without impacting the concurrent nature of Erlang because values would still be immutable.

xtho 17y ago
It nevertheless is confusing for somebody who doesn't know erlang. Even prolog uses different symbols for matching a variable and for defining a clause.
- gloob 17y ago
  And Turkish is confusing for someone who doesn't know Turkish. If you want to use a language, learn it.
  - xtho 17y ago
    An explanation for this digression from prolog syntax would have been welcome.
rvirding 17y ago
It is as you say, you must make a choice, trying to have both becomes very confusing. In LFE (Lisp Flavoured Erlang) I went the other and added proper scoping. It is the lack of scoping which I consider to be the most confusing and has caused some strange features. Having mutable variables is definitely possible but I don't really see the problems with immutable ones. You get used to it very quickly.

tb 17y ago

f() is only available in the Erlang shell/REPL. The reason it has such a short name is that it's intended for use in the shell and not in real code. Its purpose is for forgetting a variable name that you may have defined earlier during interactive testing in the shell. It's not available in compiled code and is not intended for re-assigning variables within a function.

Herring 17y ago

Functional Programming For The Rest of Us -- http://www.defmacro.org/ramblings/fp.html http://www.defmacro.org/ramblings/fp.html What works for me is thinking of fp as describing mathematical relationships instead of changing state