>> foreign import stdcall "windows.h PostMessageW"
>> postMessage :: HWND -> WindowMessage -> WPARAM -> LPARAM -> IO LRESULT
>
> Oh yea. Very nice, yes. Amazing how many of the pre-C# languages made
> such a thing so tedious.

Hey, our language is *great*! Why would you ever want to call anything else?

>> How this actually finds the necessary code to execute, I have no idea.
>
> That's why they call it "the registry".

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.

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...

>> You cannot access Haskell data from C at all. You can access C data from
>> Haskell if you're careful.
>
> OK. That's what I figured. I couldn't imagine how C was getting to lazy
> data easily.

You *can* do it of course, but it'll probably break with the next 
release of the compiler, so nobody does it. Instead, you write Haskell 
stub functions to fetch whatever item of data you want, and call that 
from C. (Or just design the program the other way around.)

I'm unsure how much runtime overhead is involved in calling between C 
and Haskell.

>> You can also build Haskell DLLs. I have no idea how that works...
>>
>> Speaking of which, GHC now supports compiling each Haskell library as
>> a DLL,
>> rather than linking them all statically. Unfortunately, this is broken
>> out-of-the-box. If you compile this way, you have to manually find all
>> the
>> DLLs your program requires and move them into the search path, because
>> the
>> GHC installer doesn't do this for you. Oops!
>
> That's why they call it the registry. :-)

The general opinion among Haskell developers is that Windows is "that 
evil platform that we shouldn't have to support". In particular, DLLs 
and the registry are both regarded as being impossibly complex to use, 
and to be avoided to the maximum extent possible.

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

>> Wouldn't converting one gigabyte of data to a new format online take
>> just as long as reloading it from disk?
>
> And yes, it would take just as long, but you don't have to do it all at
> once. You can be servicing requests, and reformatting data while you're
> not servicing requests.

OK, fair enough.

>> 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.

>>> You can also convert things slowly, using the old data in the new code
>>> until all the old code is gone, then slowly work thru the data (perhaps
>>> updating it each time it's touched) to the new format.
>>
>> This is an unavoidable requirement which *must* be met if you want
>> distributed processing. Otherwise upgrading the system requires
>> stopping the
>> entire distributed network.
>
> 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.

>> No, this is the fundamental problem with a small proof-of-concept
>> implementation exploring whether it's even slightly possible to do this.
>> Obviously the current implementation does not yet provide everything
>> necessary for production use. Nobody is claiming it does.
>
> Sure. I'm just not sure they've proved the concept if they can't handle
> that. :-)

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

>> What is needed - and the documentation makes plain that the
>> implementors are
>> quite aware of this - is some way of varifying that the identifiers
>> you send
>> actually refer to the same thing. I don't actually know how Erlang
>> manages
>> to do this;
>
> Dynamic typing. :-)

That's not an answer. Haskell is typing values sent over the wire 
dynamically too. That doesn't automatically solve the problem.

There are two things to check: data structure type names and function 
names. The Erlang answer seems to be:

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.

(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.)

2. I have literally no idea how Erlang sends functions over the wire. I 
had assumed it just sends the VM executable code over the wire. 
Obviously that only works if you're running on a VM. Haskell isn't. 
(There *is* a VM, but it's fairly slow, and has various other gotchas.) 
Haskell is sending the function name over the wire, but that only works 
if the name means the same thing at the other end.

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...

Post a reply to this message