On 5/16/2011 1:06, Invisible wrote:
> Well, no. See, if you call a Win32 function, it just works. If you call a
> function that you wrote yourself, you have to tell the linker to link the
> corresponding object code.

Unless you register it, I expect.

> As I understand it, calling Win32 works by calling a C stub function which
> does the necessary machine code magic to actually invoke the Windows kernel,
> whatever that may be. But I don't see anywhere where this gets linked in...

It's entirely possible the declaration itself generates that code, isn't it? 
I'm pretty sure that's how it works in C#: you say "C# XYZ(i) calls 
C-languge PDQ with a (short) parameter" and the compiler generates an XYZ 
function that casts its argument to a short and jumps to the PDQ function, 
basically.

> the compiler, so nobody does it. Instead, you write Haskell stub functions

Yep. Kind of like calling C++ from C.

> Which is a bit like developing software for Linux and insisting that
> everybody should avoid using Bash.

Yep. More like developing distributed programs for Linux and deciding that 
sockets are too hard to use.

>>> I'm not seeing why you would need to do this with cold code update
>>> either.
>>> You only need to shut down the processes related to the thing you're
>>> actually changing.
>>
>> Then you have a bunch of different processes on the same machine
>> fighting over resources. Sending messages between them means you now
>> have a bunch of context switches, etc.
>
> I don't follow.

It's less efficient to have the kernel scheduler scheduling the different 
processes than to have the Erlang-specific scheduler doing it. That's why 
people make 100,000 erlang tasks in one process and doing the same in Linux 
will bring the kernel to its knees, if not run you out of memory.

>> Yep. And that's why building a big system like this with static
>> type-erased data is more difficult than dynamic tagged data.
>
> ...which is why the Haskell implementation is using dynamic tagged data.

Yep. And that loses a lot of the benefits of the static typing right there.

> Can't handle it _yet_. They have concrete plans for how they would implement
> it, they just haven't yet.

Fair enough. I look forward to seeing what they come up with.

> 1. Make no attempt to verify whether data structures match at all. If the
> old code excepts data in one format and the new version expects data in an
> almost identical yet slightly different format, when the new code fires up
> it will just crash due to the data mismatch. Unless you specifically tested
> for this and wrote lots of code to make it work.

Right.

Actually, even worse, in Erlang, the likelihood is that you just leave the 
mismatched message in the buffer, which then grows until it crashes the 
whole machine with no obvious reason. One of the poorly thought-out designs 
there, methinks.

> (By contrast, Haskell might potentially be able to distinguish the old type
> and the new type at the type level, if the structure of the type has
> actually changed, and issue a compile-time warning.)

This assumes you know at compile time what types the other side is using, 
which also isn't always true. :-)

> 2. I have literally no idea how Erlang sends functions over the wire.

It's out in the erldocs somewhere, but I can't find it after five minutes of 
looking around. They specify the wire format of everything, including that.

> assumed it just sends the VM executable code over the wire.

Given that I can write a function on an x86 machine and ship it over to a 
program running on a Sparc that has been running since before I bought the 
x86 machine, yah, I'd say there's some sort of virtual code being 
transfered. :-)

> In both cases, it looks like you need a name plus some kind of version
> number, or maybe a hash of a description or something, to distinguish things
> that the programmer has assigned identical names to...

It depends on whether you're sending a function or the name of the function, 
really.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message