|Version 2 (modified by 8 years ago) (diff),|
Haskell Objective-C FFI
We aim for an extensions of the Standard Haskell Foreign Function Interface to include bindings to Objective-C. We like to make it easy to embed Haskell code in Objective-C programs as well as the other way around. Moreover, we like to be able to use object hierarchies stored in NIB files directly in Haskell code.
Consequences of the goals
We need to be able to subclass Objective-C classes (and in that process overwrite methods, add new class and instance methods, and add properties). We might be able to get away with only supporting properties (and not ivars that are directly read and written).
As far as the use of Haskell code from Objective-C goes, we can imagine two kinds of implementations: (1) We can make everything fully dynamic through the ObjC runtime at app runtime or (2) we can generate
.h files and .m stubs statically during app compile time (from within GHC).
I am guessing that (1) is easier to implement and (2) more efficient. We should try to develop a spec that allows both implementations (in that both types of implementations can be fully compliant). Then, we can start with (1) and later move to (2) if we feel it is worthwhile – get's us a running system more quickly.
Even with Option (1), where the actual class definition is dynamic, we can still provide (manually written) Objective-C header files that give class interfaces. This enables the Objective-C compiler to do type checking and should enable the use of classes implemented in Haskell in Interface Builder. (With Option (2), these header files should be generated by GHC.)
We discuss the following subtopics on separate pages:
- [ObjectiveC/ForeignDeclarations Foreign declarations for Objective-C]
- [ObjectiveC/Messaging Sending messages]
- [ObjectiveC/Classes Objective-C classes]
- [ObjectiveC/Naming Naming conventions] (they are not enforced, but recommended)
- [ObjectiveC/MemoryManagement Memory management]
Chicken scheme objc egg: http://chicken.wiki.br/objc