>> So you mean each thread waits for messages to arrive, processes them, 
>> maybe sends some other messages, and then waits for the next message?
> 
> Essentially, yes.

Seems like a conceptually simple model.

>> Mmm... In C, an integer is a "first class" thing, but that doesn't 
>> mean you can send it over a network connection, for example. They 
>> might mean that these channels only work inside a single running 
>> instance of a single program.
> 
> If you can send a channel over another channel, then all you need is to 
> encapsulate channels over sockets and you're done. If you can't send a 
> channel over another channel, then it isn't first class.

I would suggest that sending a channel over a channel is probably 
trivial, but sending a channel over a socket is probably *highly* complex...

>> Oh, OK. I assumed they all do what Haskell does
> 
> No. Generally, desktop languages that supported threading before 
> multi-CPU machines were common either fake it or use OS threads.

Oh. Really? I didn't know that...

Well, now I guess I understand why everybody gets so excited about 
Haskell's concurrency support then. :-}

>> Ah, dynamic loading is fun.
> 
> It's important for long-running programs, things with plug-ins, etc. 
> Even if it's just dynamic linking. Of course, given it's google, they 
> might very easily say "crash out if you want to load a different 
> implementation of something, because everything we write recovers 
> automatically anyway."

It's supposedly one of the big plus points of Java - not that I have 
*ever* seen *any* Java program which actually supports plugins, mind you...

As an aside, GHC theoretically is supposed to support dynamic loading. 
Good luck making it actually work though...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message