... | ... | @@ -3,7 +3,7 @@ |
|
|
## Goals
|
|
|
|
|
|
|
|
|
We aim for an extension 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.
|
|
|
We aim for an extension 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
|
|
|
|
... | ... | @@ -19,7 +19,7 @@ As far as the use of Haskell code from Objective-C goes, we can imagine three ki |
|
|
Option (1) has the disadvantage that all class initialisation code needs to be executed after the program has loaded and before any other code runs. We need to arrange that for dynamically loaded objects, too. Option (2) and (3) lead to a similar outcomes (in terms of object files), but Option (2) seems easier to implement and has some precedent in the C stubs generated for Haskell functions dynamically exported to C.
|
|
|
|
|
|
|
|
|
We require the programmer to supply headers for all Objective-C classes implemented in Haskell. This enables the Objective-C compiler to do type checking and enables Interface Builder to recognises properties used as outlets.
|
|
|
We require the programmer to supply headers for all Objective-C classes implemented in Haskell. This enables the Objective-C compiler to do type checking and enables Interface Builder to recognise properties used as outlets.
|
|
|
|
|
|
## Architecture
|
|
|
|
... | ... | |