
This thread is obviously a source of much fun. I will play too. Cristian Baboi wrote:
On Fri, 28 Dec 2007 18:32:05 +0200, Jules Bean
wrote: Cristian Baboi wrote:
Let me ask you 3 simple questions. Can one use Haskell to make dynamically linked libraries (DLL on Windows, so on Linux) ?
The short answer is yes.
The long answer is that this is not a feature of haskell, but rather a feature of certain programs, which happen to be mostly but not entirely written in haskell, in particular, the haskell compiler. GHC can produce dynamically linked libraries.
What you choose not to notice is the context in which I asked these questions. The context is: Haskell functions as first-class objects. What I am interested in the first place is dynamically linked libraries written in Haskell and used in Haskell. The interface with other languages like C come second.
If yes, what is in them ?
Object code, mostly. Sometimes a little data.
What is the definition of an entry point in Haskell ?
"Haskell" does not have such a concept. At all. An implementation may have such a concept. Most people on this list define "Haskell" as any attempt at an implementation of one of the standards which define Haskell, most recently the Hakell 98 standard. This can be nhc / yhc / ghc / hugs / winhugs / helium / jhc. Some of these compile to native code, some compile to byte code for a virtual machine. If an implementation can compile separately, then it might support dynamic libraries. If so then a specific version of that compiler will define its own implementation specific concept of an entry point.
What is the semantics of those entry points ?
It depends. For recent ghc versions, see its user manual: http://haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#ffi-library http://haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html Other note: An imperative language, such as C++ or Java, specified the binary output of any instance of the compiler. Class methods will have very specific names and addresses. In C++ you can even get the member-function pointer values and examine the byte offsets in the object. In Java one gets a very specific layout of bytecode in a class file. "Haskell" is a declarative language. It does not specify anything about the implementation's internals. It specifies only properties like "non-strict". The fact that ghc uses lazy evaluation is merely an implementation detail, chosen as a way of satisfying the "non-strict" requirement of "Haskell". The output of a "Haskell" compiler is free to take all the source code and implement things with jumps and branches that look absolutely nothing like function calls. -- Chris