Converts any integer number (such as 123456000999) into a string ("one billion two hundred ninety-three million one hundred two thousand one hundred").
I don't know. Because there's a bit of work and code that has to be executed for the garbage collector and other systems, I guess.
Lardmeister: a couple reasons. First, every GHC executable comes with the RTS, runtime system. This handles garbage collection, threading (or lack there of), profiling, and so on. There's actually quite a few options for it. This RTS eats up a couple hundred KB.
Second, the executables are statically linked - there is no libh along the lines of libc. Dynamic/shared libraries are coming; I'm not sure when, but I heard the GHC devs got it working on some non-Linux platform already, so my guess would be 6.10.
And third, I believe GHC by default leaves all the debugging symbols and whatnot in. Running strip might reclaim some space.
Finally, I'd like to note that binary size isn't so terrible since a lot of the code size is a fixed cost as I mentioned - it looks worst for a hello world. My customized XMonad, when stripped, is about 2.4 megabytes, while your hello world example would lead one to suspect a size considerably worse... Also, come on, this is an old and uninteresting topic. Does it bother you when you run a Python or Java or Common Lisp app that the interpreter is like 20-60 megs?
It is great. However, there is probably a mistake: There slould be:
| otherwise = [digiteen hundi, "hundred and", twodigit twodi]
| otherwise = [digiteen hundi, "hundred", twodigit twodi]
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.