On 5/17/2011 1:07, Invisible wrote:
>> Unless you register it, I expect.
>
> Well, no, what I'm saying is that if you call a function that's defined in
> (say) windows.h, the linker somehow "finds" it.

Right. It's probably in the C runtime.

> But if you wrote some C
> source code of your own, you have to tell the linker to link in the object
> code or it complains it can't find it.

Right. Unless you register it. Then the linker looks up the code in the 
registry and links it against the file that the registry says the code is 
in. That's what the registry is for, and why it's called a registry.

You may need to make it a COM DLL first to register it; I don't remember the 
exact details any more.

> (The answer is probably something like "GHC automatically includes the Win32
> files at link time".)

That's my guess.

> If I do a "foreign import", the Haskell compiler generates a Haskell
> function which calls the corresponding C function. Which is fine if you're
> statically linking the C code into your binary. But you don't link the
> Windows kernel into your application, do you? It does some weird magic with
> processor rings and code gates to enter kernel mode to run the code.

In every system I've ever used, the "weird magic" is in a linker file that 
always gets loaded. For example, msvcrt.dll (Microsoft visual C run time) 
for Windows, glib for GCC under Linux, etc.

> I'm no expert, but as I say, I was under the impression that the usual way
> to access a DLL is to link in a small C stub which defines the code
> necessary to dynamically find and execute the exported functions from the DLL.

Or branch to a jump table that the loader fills in with addresses from the 
DLL when it loads the DLL, which it loads based on the headers of the program.

Most systems do almost all of this automatically specifically because C 
doesn't have any standard syntax for doing this. I suspect if 
dynamically-loaded code was the norm in C from the beginning, much less 
would be automated by the OS's loader.

> Personally, I thought "DLL hell" went away about 10 years ago...

Yes, pretty much.

> Right. So all you're saying is that OS processes are heavier than Erlang
> processes.

Well, much heavier than Linux or Windows processes. By many, many orders of 
magnitude. There are OSes where processes are very light, like Singularity, 
Mach, AmigaOS, etc. Generally what you hear referred to as a "microkernel" 
is a kernel where processes are so lightweight that you can afford to put 
each device driver and file system in its own process.

> One thing Erlang can do (and Haskell can't, easily) is that because Erlang
> is a VM, you can have several unrelated Erlang applications running on the
> same VM.

Yes. Indeed, the whole point of the VM is to be a virtual machine, so the 
idea of an "application" is a user-level construct, not something built into 
the language.  (In much the same way that a "login" is a user-level 
construct in UNIX/Linux, whereas in most other OSes, it's an OS-level 
construct.)

> Yes, the entire program is statically typed, but this one tiny part where
> you have to do a simple runtime type check automatically COMPLETELY DESTROYS
> EVERY SINGLE ADVANTAGE OF STATIC TYPING!

I didn't say that. I said it loses a lot of the benefits, where "benefits" 
are "guarantees" in my mind.

Now, in this particular case, it probably is doing enough work in the 
connected set of processes that converting from dynamic to static typing is 
worthwhile. In the discussions we were having before, I was talking about 
things like web pages, that almost never do any significant processing on 
their own at the server, so statically typing a web page where you're 
translating dynamically typed SQL results into HTML doesn't really help to 
have static typing. I.e., when it's not one tiny part but rather a majority 
of the program, it's worse.

> Basically you need to manually make sure you send a version number at the
> start of your message exchange, or something like that, and make sure that
> all servers and clients you write can handle all versions of the protocol.

Or you just check the types and do the right thing with them. Of course, 
knowing what the right thing is can be difficult. E.g., if you have been 
working with 2D longitude/latitude, and the new version needs altitude also, 
you could have all the places that take a 2-element tuple start also working 
with a 3-element tuple and asking how many elements it has, then start 
generating 3-element tuples. The number of elements in the tuple can serve 
as your version number.

> Or design the protocol so that it never needs to change. (Which is not
> infeasible if you can send code as part of the protocol I suppose...)

Well, they handle it by letting you upgrade the code.

> Not really. When you compile v1, you assume that the other side will be v1
> as well. When you compile v2, the compiler checks what you changed, and
> warns you if you don't explicitly handle the v1 data (unless it's identical).

That's fair. It would be interesting to see how that's specified.

> The Haskell implementation has a potential advantage in that you can specify
> precisely how to serialise stuff if you want to.

You just do that in code with Erlang. I.e., you write your own serializer, 
or you send a message to a local agent that then sends the message to the 
remote agent that has only what you want.

> And yet, that would seem rather heavy compared to just sending a function
> name (or rather, a *unique* function identifier),

Not all functions have names. For the functions that have names, I believe 
you just send the fully-qualified name of the function. (And since function 
names are atoms, the actual text of the function name is cached after the 
first time, so you don't have to send more than "the 37'th function I've 
sent you" next time.)

If you send a lambda, I believe it sends the bytecode. There may be caching 
involved there too, but I don't remember.

I was too awed by the landmines in the data format to remember the other 
details.

> Come to think of it, I'm still figuring out how it manages to send atoms...

It sends them as text, the first time.

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

Post a reply to this message