On 13/05/2011 05:43 PM, Darren New wrote:
> On 5/13/2011 4:32, Invisible wrote:
>> 4. Really easy to link to C for performance-critical sections.
>
> Do you have an example of what you need to do in Haskell to link to a
> simple C function? Is it easy for C to call Haskell functions?

I'm fairly sure I posted one in the other group a while back. Heck, I 
even got qsort() from stdlib.h to work arbitrary Haskell data types, 
just because Warp said it wasn't possible.

Actually calling a C function is trivial. Passing a Haskell function 
pointer to C is trivial. What is very *non*-trivial is getting data 
marshalling and memory management to work.

>> Implementing Erlang's distributed processing model in Haskell. (This is a
>> work in progress. I doubt it's production-ready yet - or any time soon.)
>
> Yah. Python has one of these too.

I'm sure lots of people are doing this. After all, the basic 
abstractions are not complex.

>> Notable by its absence is hot code update. Some commentators have
>> noted that
>> if you actually care about high availability, you'll be using multiple
>> hot-spares anyway, and so long as you don't take down all systems at
>> once,
>> you can just take one offline, update it, put it back online, and move
>> on to
>> the next one.
>
> The problem with this is it takes *incredibly* longer. You have to write
> all the current data out to disk, shut down cleanly (including all the
> processes running there whose code you are *not* updating), then modify
> the code, then start everything up again, and read everything back in
> off disk.

Perhaps. Perhaps the data is already in some distributed database, so 
it's already persistent regardless of whether a node dies or not. (Isn't 
the system supposed to recover from node death anyway?)

> With Erlang's hot update, the data stays in memory. If you're fixing a
> bug, you don't have to save out and then reload dozens of gigabytes of
> in-memory database just to change the line. Plus, you now have to write
> all the code to shut down cleanly and start up cleanly again, and track
> which tasks are running in the same process as you're shutting down,
> shut them down too, etc.

With hot update, you *still* have to manually write a bunch of code to 
do any data conversions if data structures have changed, or do invariant 
checks if the data's invariants have changed. Either way, you gotta 
write code.

>> All of which obviously fails spectacularly if sender and receiver aren't
>> running the same version of the same program. ;-)
>
> It also fails if the sender and receiver aren't using the same version
> of the data structures.

Yeah. As I say, the current system is entirely predicated around 
everybody having the same code. As soon as that's not true, it's game over.

Obviously that needs fixing for a non-toy implementation.

> As soon as you have half your code updated to be
> using floats instead of integers, now you have to have some way in your
> *old* code to be able to know you're getting *new* messages and how to
> handle them. That can be rough with static typing.

It's already dealing with receiving messages of arbitrary type even in 
the presence of static typing. All that's needed is some way to compare 
types beyond "do they have the same name?"

>> 1. Every process implicitly has a "mailbox" that can be used to send or
>
> That's the Erlang approach, except of course it's dynamically typed.
>
>> 2. You can explicitly create typed "channels". Each such channel can
>
> That's the NIL / Hermes approach, both of which were statically typed.
> The advantage of this is channels can become first class. You can pass
> them between processes and have different channels connected to
> different processes. You can use it for security, too - if I don't give
> you a channel to the screen but only to your window, you can only write
> to your window, and it's trivial to verify that.

Yeah, passing channels around looks quite useful. It just seems a pitty 
to have more or less duplicated functionality in two incompatible 
systems - mailboxes and channels. Couldn't they have implemented a 
mailbox as a channel of arbitrary type or something?

>> (This is not livelock,
>
> I'm not sure about that.

Well, OK, let me rephrase: There is no situation where an STM program 
gets so stuck that nothing can make progress. The worst that can happen 
is that one particular transaction gets stuck. (And they're talking 
about adding an API to detect / do something about this if it actually 
happens.)

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

Post a reply to this message