Knowing the Haskell community, they could probably convert GHC Core into idiomatic Objective-C if they really wanted to, but it's not necessary. RubyMotion and other platforms are accepted because they stick to Apple's guidelines. The same would go for a GHC-iPhone platform.
Indeed. I did this with one program: I wrote some number crunching code in Haskell, and exposed some functions to C via the FFI. Then I wrote the user interface in Cocoa/Objective-C. The primary thing that requires some though is how to pass data between C and Haskell. You usually end up marshaling/unmarshaling some structs:
Is the gain rom Haskell worth the impedance mismatch of cross communication?
I guess it depends on how much you love Haskell ;), and the usage scenario. I think using Haskell's FFI in this direction is especially attractive if you prefer to write most code in Haskell, but need some functionality that does not map naturally to a pure functional language (such as GUIs in Cocoa). If you want to mix a lot of imperative and functional code seamlessly, F#/C# or Scala/Java are probably better options.
Thanks what's the size like? The last time I built a Haskell application it was quite large.
4969KB with the runtime and package dependencies linked in the dynamic library (Darwin, 64-bit). Since I do not have dynamic libraries of its dependencies installed, I cannot quickly try a completely dynamic version...
interestingly Wp7 is by far the easiest mobile to get a good functional language running on.
I purchased a Windows Phone last week (iOS user here) to see how it works, and I am surprised how good the integration is.
In theory, yes. In practice, no. The C emitted from compilers is usually an awful mess that looks like Assembly code and it might not have sane function entry points so it could be used as a library. Then you need to get the runtime system (garbage collector, etc) up and running to run your code. It's by no means impossible but it's very impractical.
Historically, C was used to implement many (functional) programming languages because it provided a convenient compiler back end and a well-defined intermediate representation between the front end and the back end. Not because you could compile to C and use your code from C.
Indeed, the FFI in GHC is one of the best ones out there. It makes it convenient to call C from Haskell and vice versa(!). I wish every language had an FFI and RTS that good!
