Cross compilation is not yet supported. You want to build on osx/intel and target ios/arm. Not yet. ghc still needs to target the platform it was built on.
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!
The x86 and x64 have interesting hacks in the asm they generate. For example, thread switching is done not by a conditional jump, but by self-modifying code (there's some nops in the main loop, and they get overwritten with a jmp when it's time to preempt). What cool architecture-specific hacks does the ARM version use?
I assume you refer to the co-operative thread switching done by the GHC runtime to achieve co-operative multitasking with Haskell's green threads? I thought this was done by trashing all the registers (pushing live regs to stack) in the compiler back end and then swapping the stack pointer in the runtime. Are you sure about the nop's in the main loop?
I, too, would like to know how this works on ARM and other non-x86 platforms. Do they even have this feature supported on ARM? (ie. compile with ghc --threaded and then add RTS parameters as needed when executing)
GHC uses pre-emptive thread switching, not co-operative thread switching. Threads are forced by the runtime to be switched out -- they have no choice in the matter -- based on rts interrupts.
Typically, threads will be switched when they allocate.
> GHC uses pre-emptive thread switching, not co-operative thread switching.
> Threads may be switched when they allocate.
If threads are scheduled in and out when they allocate memory or are about to issue a possibly blocking system call, it's called co-operative multithreading, isn't it?
If the thread execution was stopped using external means like a timer interrupt, that would be pre-emptive. Some definitions of pre-emptive involve the ability to stop a lower priority thread in favor of a higher priority thread that becomes ready when a syscall is finished.
The best I understand the situation, Haskell's green threads voluntarily (co-operatively) give up their time slice (for another green thread) when allocating memory or doing I/O. Haskell's green threads run on top of several native threads that are pre-emptively scheduled by the operating system.
What you describe is the actual procedure of switching threads. What cheatercheater describes is the mechanics of initiating this switch. You have "checkpoints" in the thread, where the thread finds out if it is to be descheduled and performs a conditional branch to the code that does what you described.
Apparently in GHC code, there is no conditional branch instruction, an unconditional jump is generated on the fly, probably to avoid branch mispredictions.
