On 5/14/2011 7:53, Orchid XP v8 wrote:
> 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.

> How this actually finds the necessary code to execute, I have no idea.

That's why they call it "the registry".

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

> Memory managemet is fun. (Principly because if you get it wrong... well, you
> know what happens.) There are Haskell libraries for allocating and freeing
> values that the GC doesn't move around (so-called "pinned memory").

In C#, you pin the memory from C# and then invoke your C code. Similar idea.

> You can also arrange for the main() function to be implemented in C rather
> than Haskell. (I believe you have to make sure main() calls some Haskell
> startup functions though.) In this way, you can build a Haskell program that
> calls C, or a C program that calls Haskell.

Yep. Ada even standardizes the names of the functions for this stuff.

> 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 *abstraction* is simple. The *implementation* is not. The same is true
> of many, many things. ;-)

It's simple after it's pointed out, methinks. $1 - hammer tap. $99 - knowing 
where to tap.

> Wouldn't converting one gigabyte of data to a new format online take just as
> long as reloading it from disk?

I don't know what you mean. You have to get it off the disk and into memory, 
if you've terminated the process and start it up again.

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.

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

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

>>> 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.
>>
>> That, I think, is the fundamental problem with systems like Haskell, and
>> the fundamental reason why dynamic typing may very well win in this
>> situation.
>
> 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. :-)  Sort of like the STM proof of concept in .NET. ;-)

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


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

Post a reply to this message