4 ms·

What would make this more attractive to me is a mechanism for local mutable state. Some algorithms are just easier to express if you're allowed to change the va

by pjscott 16y ago

What would make this more attractive to me is a mechanism for local mutable state. Some algorithms are just easier to express if you're allowed to change the values of some local variables. Erlang has no shared mutable state, but as Haskell's State monad shows, it's perfectly possible (and often useful) to keep mutable state boxed off safely. Since this can be transformed to tail-recursion, you should be able to implement it on the Erlang VM without too much trouble. Getting a convenient syntax and doing the transformation would be the hardest part.

hvs 16y ago
I'm a huge fan of Erlang (hot-swapping code for the win!), but this is probably my biggest peeve with it.
wnoise 16y ago
There is still the process dictionary, but it's a bit unwieldy. http://www.erlang.org/course/advanced.html#dict http://www.erlang.org/course/advanced.html#dict
- yosh 16y ago
  I've also used private ETS tables for this.
- gordonguthrie 16y ago
  Yes the process dictionary seems attractive, but you will come to regret it. It will always bit you in the bum, don't do it, don't do it, don't do it.
  - nathanwdavis 16y ago
    Can you explain why please?
    - gtani 16y ago
      background on PD (tho i havent kept up with developments in R14, i can't say whether everything below still valid http://groups.google.com/group/erlang-programming/browse_frm/thread/15e3718c9fab68f7/c64371fee1f859f6?tvc=1#c64371fee1f859f6 http://groups.google.com/group/erlang-programming/browse_frm... ------------ (Oct 09) http://groups.google.com/group/erlang-programming/browse_frm/thread/8c5aac9e0ae91895/72683f33f1c4be85?tvc=1#72683f33f1c4be85 http://groups.google.com/group/erlang-programming/browse_frm...
      - nathanwdavis 16y ago
        Hey, great links. Thanks!!
        gtani 16y ago
        I think the consensus in 2009 was you should see how far you can get with ETS (and this will motivate me to read the R14 release notes), PD's are kind of like lisp reader macro's, very sharp and very slippery. There are many threads in the google group if you want more argumentage.
    - gordonguthrie 16y ago
      It has global state. In erlang processes are long lived and you bring functions to them to do stuff. Suddenly you will do something and a piece of state that you weren't expecting will be in your process dictionary... Some erlang processes run for literally years - and exist over multiple releases of the software. Reasoning about how something did or did not get into the process dictionary is for the birds.
metabrew 16y ago
there are some hipe_bifs that let you do naughty and unpure things like destructive modification of arrays and what-not.
- gordonguthrie 16y ago
  With all due respect metabrew, if you do that you are a nutter. Non-mutability is not some crazy quick left there as an afterthought - it is at the core of Erlang - it is how you build reliable systems in the presence of errors.
- elgenie 16y ago
  And nifs can be made to do most anything you want to module-private data. But if you're cheating on purity, there better be a darn good reason.
bascule 16y ago
Hi, I created Reia. I used to agree with you but now I don't. I was particularly moved by some of what Joe Armstrong, Erlang's creator, had to say in the book "Coders at Work". He noted that after attending several functional language conferences, immutable state was much more a common quality of truly functional languages than other things people typically associate like static typing or lazy evaluation. Reia is an immutable state language, and I think it's primarily a functional language, but one with a lot of features that make it less painful to use than languages like Erlang or Haskell. In a language like Erlang, immutable state allows you the potential to send zero copy messages between actors. This can be hugely beneficial for exchanging state in a shared nothing system like Erlang. That said, the Erlang VM doesn't work this way. There have been experiments like the shared and hybrid heaps to enable this, but they've largely been failures, not because they're conceptually flawed, but because the garbage collection in Erlang is relatively simplistic. Erlang processes are independently garbage collected so they never needed to deal with concurrent garbage collection or a shared heap before. Erjang (Erlang on the JVM) uses Java's shared heap and lets you use the wealth of pluggable garbage collectors available on the Java platform. In a quick test of the "chameneos-redux" benchmark on Erlang BEAM vs. Erjang, a benchmark which generates lots of messages and can benefit immensely from sharing state, Erjang was about twice as fast as Erlang.
- pjscott 16y ago
  I'm definitely not talking about mutable state that's shared between processes. I don't want global variables, or any such thing. I just want to be able to write little blocks of code where I can change local variables. To illustrate what I'm getting at, here's some code in JavaScript which will calculate the nth Fibonacci number: function fib(n) { var a = 0, b = 1; for (var i = 0; i < n; i++) { var temp = a + b; a = b; b = temp; } return 'fib(' + n + ') = ' + a; } It uses a for loop. Of course, you could do the same thing with a tail recursive function, or probably some higher-order-function trickery, but a for loop is a very direct way of putting it. But how do we implement this on the Erlang VM? It doesn't support any of this dangerous mucking around with the values of variables! As you rightly point out, there are good reasons for this. What we can do is convert this to, essentially, continuation-passing form. This looks awkward is JS, but it gives the same answer: function fib_cps(n) { function forloop(a, b, i, cont) { if (i < n) { return forloop(b, a + b, i + 1, cont); } else { return cont(a); } } return forloop(0, 1, 0, function(result) { return 'fib(' + n + ') = ' + result; }); } The for loop was converted to a tail-recursive function which takes the values of all the mutable local variables and tail-calls some function with (some subset of) these mutable local variables. Since Erlang has proper tail-call support, this should be no problem. And it doesn't require any modification to how heaps are handled, or Erlang's garbage collection scheme, or anything. It "just" takes some compiler work. That's what I had in mind. Does it sound more reasonable?

by pjscott 16y ago

hvs 16y ago

I'm a huge fan of Erlang (hot-swapping code for the win!), but this is probably my biggest peeve with it.

wnoise 16y ago

There is still the process dictionary, but it's a bit unwieldy. http://www.erlang.org/course/advanced.html#dict http://www.erlang.org/course/advanced.html#dict

yosh 16y ago
I've also used private ETS tables for this.
gordonguthrie 16y ago
Yes the process dictionary seems attractive, but you will come to regret it. It will always bit you in the bum, don't do it, don't do it, don't do it.
- nathanwdavis 16y ago
  Can you explain why please?
  - gtani 16y ago
    background on PD (tho i havent kept up with developments in R14, i can't say whether everything below still valid http://groups.google.com/group/erlang-programming/browse_frm/thread/15e3718c9fab68f7/c64371fee1f859f6?tvc=1#c64371fee1f859f6 http://groups.google.com/group/erlang-programming/browse_frm... ------------ (Oct 09) http://groups.google.com/group/erlang-programming/browse_frm/thread/8c5aac9e0ae91895/72683f33f1c4be85?tvc=1#72683f33f1c4be85 http://groups.google.com/group/erlang-programming/browse_frm...
    - nathanwdavis 16y ago
      Hey, great links. Thanks!!
      - gtani 16y ago
        I think the consensus in 2009 was you should see how far you can get with ETS (and this will motivate me to read the R14 release notes), PD's are kind of like lisp reader macro's, very sharp and very slippery. There are many threads in the google group if you want more argumentage.
  - gordonguthrie 16y ago
    It has global state. In erlang processes are long lived and you bring functions to them to do stuff. Suddenly you will do something and a piece of state that you weren't expecting will be in your process dictionary... Some erlang processes run for literally years - and exist over multiple releases of the software. Reasoning about how something did or did not get into the process dictionary is for the birds.

metabrew 16y ago

there are some hipe_bifs that let you do naughty and unpure things like destructive modification of arrays and what-not.

gordonguthrie 16y ago
With all due respect metabrew, if you do that you are a nutter. Non-mutability is not some crazy quick left there as an afterthought - it is at the core of Erlang - it is how you build reliable systems in the presence of errors.
elgenie 16y ago
And nifs can be made to do most anything you want to module-private data. But if you're cheating on purity, there better be a darn good reason.

bascule 16y ago

Hi, I created Reia. I used to agree with you but now I don't. I was particularly moved by some of what Joe Armstrong, Erlang's creator, had to say in the book "Coders at Work". He noted that after attending several functional language conferences, immutable state was much more a common quality of truly functional languages than other things people typically associate like static typing or lazy evaluation. Reia is an immutable state language, and I think it's primarily a functional language, but one with a lot of features that make it less painful to use than languages like Erlang or Haskell. In a language like Erlang, immutable state allows you the potential to send zero copy messages between actors. This can be hugely beneficial for exchanging state in a shared nothing system like Erlang. That said, the Erlang VM doesn't work this way. There have been experiments like the shared and hybrid heaps to enable this, but they've largely been failures, not because they're conceptually flawed, but because the garbage collection in Erlang is relatively simplistic. Erlang processes are independently garbage collected so they never needed to deal with concurrent garbage collection or a shared heap before. Erjang (Erlang on the JVM) uses Java's shared heap and lets you use the wealth of pluggable garbage collectors available on the Java platform. In a quick test of the "chameneos-redux" benchmark on Erlang BEAM vs. Erjang, a benchmark which generates lots of messages and can benefit immensely from sharing state, Erjang was about twice as fast as Erlang.

pjscott 16y ago
I'm definitely not talking about mutable state that's shared between processes. I don't want global variables, or any such thing. I just want to be able to write little blocks of code where I can change local variables. To illustrate what I'm getting at, here's some code in JavaScript which will calculate the nth Fibonacci number: function fib(n) { var a = 0, b = 1; for (var i = 0; i < n; i++) { var temp = a + b; a = b; b = temp; } return 'fib(' + n + ') = ' + a; } It uses a for loop. Of course, you could do the same thing with a tail recursive function, or probably some higher-order-function trickery, but a for loop is a very direct way of putting it. But how do we implement this on the Erlang VM? It doesn't support any of this dangerous mucking around with the values of variables! As you rightly point out, there are good reasons for this. What we can do is convert this to, essentially, continuation-passing form. This looks awkward is JS, but it gives the same answer: function fib_cps(n) { function forloop(a, b, i, cont) { if (i < n) { return forloop(b, a + b, i + 1, cont); } else { return cont(a); } } return forloop(0, 1, 0, function(result) { return 'fib(' + n + ') = ' + result; }); } The for loop was converted to a tail-recursive function which takes the values of all the mutable local variables and tail-calls some function with (some subset of) these mutable local variables. Since Erlang has proper tail-call support, this should be no problem. And it doesn't require any modification to how heaps are handled, or Erlang's garbage collection scheme, or anything. It "just" takes some compiler work. That's what I had in mind. Does it sound more reasonable?