judah/coremac

Haskell bindings to the C APIs for iOS and OS X

coremac's Issues

Abstract pointer types

One design difference between your library (let's call this CoreMac) and mine (let's call this CoreFoundation) is treatment of pointer types. CoreMac treats all pointers as Ptr (), whereas CoreFoundation uses pointers to abstract types. Consequently, the type of withObject varies between CoreMac and CoreFoundation, and CoreFoundation uses a type family which CoreMac doesn't.

The advantage of the CoreFoundation approach is slightly more cross-language type safety, when combined with c2hs {#pointer ...#} hooks. For example, Haskell's type system will catch our mistakes if we try to construct a Data object from a CFStringRef.

There are a few administrative disadvantages to the CoreFoundation approach which arise from the need to keep c2hs aware of the {#pointer...#} hooks:

• some import ... statements need to be changed to c2hs {#import ...#} statements.
• as a result of the {#import ...#} statements, c2hs needs to be run on the *.chs files in dependency order. Cabal won't ensure this by itself, so this requires keeping the exposed-modules field in the cabal file in dependency order.

My opinion is that the extra type safety is worth the slight increase in complexity, but I'd be interested to hear your thoughts. As an experiment, I tried changing CoreMac to the CoreFoundation approach; see 1, 2.

Phantom type parameters for Dictionary and Array

In my CoreFoundation package, I give phantom type parameters to Array and to Dictionary representing the types of values they store, so the types are Array a and Dictionary k v.

While some CoreFoundation routines will just return Array Object (which is no more useful than CoreMac's Array), property lists are notable in having more useful types: their arrays and dictionaries are always Array Plist or Dictionary String Plist.

As a test, I integrated this design into CoreMac; see 1, 2.

New approach to mutability

Unlike my CoreFoundation code, CoreMac provides some support for mutable objects. However, I have two problems with the way it is implemented:

• functions like getText :: String -> IO Text reside in the IO monad for fear that their argument will be modified in the future; this is unfortunate for the (common) case when the argument is genuinely immutable
• there is no support for the ST monad.

I have just tried out a new approach, which is similar in design to the vector package.

This approach solves the above issues, but has the disadvantage that functions like getText must exist in two versions: one version for mutable strings, and one version for immutable strings.