If they're immutable, then great. But using shared memory to transfer state is flawed, and can cause race conditions, etc. That's why we're using the actor model to begin with, right?
I suppose they can't really be immutable, or we couldn't do hot code loading. How does Erlang do it?
Heh, you're right. So, in that mindset, why not give a lot of nice macros for controlling share vs copy, and make the default be copy? Then programmers could control nearly everything. Of course, they could always hack on your vm if they really wanted tons of control.
But still, concurrent writing to a global variable sounds dangerous.
I kind of like the idea of them being "registered processes." I'll have to do some more thinking on that.
>It doesn't, actually...
Yes, that answers some of the question, but I was a bit more interested in how they implemented their hot code loading. The code still exists for a while as the existing processes continue to use it. But they eventually phase out the functions and swap to the new ones.
IMHO, hot code loading is a very nifty feature. Combined with remote REPL makes it especially useful. I don't know how well current lisps support hot swap, but I don't think it can work effectively without a concurrent system.
> Yes, that answers some of the question, but I was a bit more interested in how they implemented their hot code loading
It's in the OTP library actually. For example, they have a standard gen_server module. The gen_server would look approximately like this in snap:
(def gen-server (fun state)
(<==
('request pid tag param)
(let (state . response) (fun state param)
(==> pid (list 'response tag response))
(gen-server fun state))
; hot code swapping!!
('upgrade new-fun)
(gen-server new-fun state)
('stop)
t))
So yes: hot swapping just means sending in a message with the new code ^^
It's actually more complex than that - they generally make messages include a version number so that nodes with new versions can communicate to nodes with older versions. This versioning is, in fact, part and parcel of the gen_server series of functions. Requests to servers are made via functions which send a message (with tags and other metadata such as versions abstracted away) and wait for a receive.
I think what they say is, the programmers good at concurrency write the gen_server and other parts of the OTP, while the average programmers write application code ^^
Much of Erlang isn't implemented in the VM level ^^
It makes sense that they wouldn't do that at the vm level. Your code even makes sense, though I thought "let" only assigned one variable.
I'm still not quite able to read arc fluently, so any explanations of the subtle that I likely missed will always be appreciated. Come to think of it, any explanations of any code would be nice, as the thoughts and reasons behind code don't always come out in the source itself. And I also like learning new things :)
I'm using pattern matching. Although Arc doesn't actually have pattern-matching built in, someone wrote a pattern matching library a long time ago using macros: http://arclanguage.com/item?id=2556http://arclanguage.org/item?id=1825 . The modern evolution uses something like p-m:def to define a pattern-matching function, p-m:fn to create an anonymous pattern-matching function, etc.
('request pid tag param)
The pattern above means "match a 4-element list, whose first element is the symbol 'request, and which has 3 more elements that we'll call pid, tag, and param".
(let (state . response) (fun state param)
This is a destructuring. It simply means that (fun state param) should return a cons cell, with the 'car of the cell being placed in state and the 'cdr being placed in response. So we expect fun to return something like (cons state response)
(==> pid (list 'response tag response))
Note the use of 'tag here. We expect that 'tag would be a 'gensym'ed symbol, and is used in pattern matching so that the client can receive the message it's looking for.
(gen-server fun state))
Plain recursion.
; hot code swapping!!
('upgrade new-fun)
(gen-server new-fun state)
