On Thu, May 30, 2013 at 11:46 AM, Kees Bleijenberg < k.bleijenberg@lijbrandt.nl> wrote:

Brandon, thanks again for your explanation Are you sure about the non existing search order for dynamic loaded dll’s? I.e. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).as... there is a search order, starting with the current directory (I think).

There is a search order. What I said is that there are no standard locations to install things. That is, every library package stows stuff in its own directory structure and no compiler can possibly know all the places it needs to look to find every library off in its own directory.

I don’t understand why the linker needs to see the dll anyway.

Because it's better to catch "that symbol doesn't exist" at build time instead of throwing an ugly error at runtime, among other things.

possible in Delphi. Is Haskell dynamic loading more limited?

There are ways to do that kind of dynamic linking; this is not one of them. C and C++ don't automatically dynload the way you're thinking either, because you should test for the DLL you're distributing (you are distributing it, right, not forcing the end user on a wild goose chase to find their own copy of the DLL, hoping it's the right/compatible version, and figure out where to put it so your program will run?) being the right one *when you build the program*, not defer that test until it is run. If you think about it, this is very similar to doing your type checking at compile time instead of runtime. If you want lazy type checking, why are you using Haskell? If you want lazy library checking, why are you using a compiler? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net