5 ms·

I'm also intrigued. How would one program for iOS in a practical sense with Haskell? A great deal of iOS programming, as I understand it, is navigating the APIs

I'm also intrigued. How would one program for iOS in a practical sense with Haskell? A great deal of iOS programming, as I understand it, is navigating the APIs and libraries provided by the SDK... is this a simple task in Haskell? The FFI is something I haven't really dealt with much yet. I guess people could/will start writing wrapper libraries?

JoshTriplett 13y ago
Haskell has one of the best FFIs I've ever seen; calling C code from Haskell is quite trivial, and you can write all of the necessary wrapper code and objects (such as automatic memory management or object destruction) in Haskell using common wrappers. I'd also highly recommend c2hs for writing new wrapper libraries.
- lucian1900 13y ago
  Part of the problem is that iOS APIs tend to be Objective-C, which is somewhat harder to wrap in Haskell.
  - gregschlom 13y ago
    Not really, it's quite easy to call Objective-C methods (or more correctly, to send messages to Objective-C selectors) and perform other Objective-C-related tasks from C. See: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html https://developer.apple.com/library/mac/documentation/Cocoa/... This is actually what the Objective-C compiler does. It translates your Objective-C code to C method calls.
    - chc 13y ago
      It's not that easy. I mean, just sending a message could entail one of objc_msgSend, obj_msgSend_stret or objc_msgSend_fpret, and which one you want to use is not always as clear-cut as you might prefer (http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_explain_objc_msgSend_stret.html http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_e...). And then there's the hassle of defining classes dynamically, which entails six function calls just to create a class with one empty method, and one of those essential functions is not actually provided for you AFAIK unless you're using Apple's compiler where it's a builtin, so you'll need to write it yourself. It's not ridiculously hard, but it's somewhat less easy than normal C FFI.
      - iand675 13y ago
        The other hard part about it is that Haskell's FFI doesn't support variadic functions in a friendly way, which makes argument passing that much trickier.
        chc 13y ago
        There is a similar problem with objc_msgSend in C: Methods with certain argument types can't be called with a normal objc_msgSend(). Instead, you need to create a specifically typed function pointer and assign objc_msgSend to it. I think a similar solution would be necessary with Haskell.
        iand675 13y ago
        I'd appreciate seeing a link to an example of this. I put a decent amount of work (a few years ago) into writing some bindings in Haskell to the objc runtime, but ended up shelving it until I could come up with a satisfactory solution to the variadic function dilemma.
        chc 13y ago
        Here are a couple of Stack Overflow answers that illustrate how you do it in Objective-C: http://stackoverflow.com/a/2573949 http://stackoverflow.com/a/2573949 http://stackoverflow.com/a/18689338 http://stackoverflow.com/a/18689338 If you're interested in the nitty-gritty of how objc_msgSend works, bbum from Apple wrote up a great low-level walkthrough a few years back: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/ http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-th...
        JoshTriplett 13y ago
        If you just need to call variadic functions with a specific parameter list determined at compile time, that's easy with the existing FFI; just write a prototype for the function for any given set of arguments you want to call it with. (For instance, you can have an FFI binding printf_int_float :: CString -> CInt -> CFloat -> IO CInt .) If you really need to construct calls at runtime and you don't know the argument list at compile time, there's a Haskell binding to libffi. However, you generally only need that if you're writing a language interpreter or similar.
- dbaupp 13y ago
  Doesn't calling C code interact poorly with green threading? (I assume that handlers that make it act slightly sanely exist, but I imagine the cost of setting up native threads for FFI is rather high.)
  - chowells 13y ago
    Native threads for FFI calls are pooled. It's not cheap, but it's not too expensive either.
chc 13y ago
I think the idea is that you would use the standard tools for the edges of the program with a Haskell core underneath handling the thinky bits. (I have no experience at all doing this, but it seems like the natural use case.)

JoshTriplett 13y ago

Haskell has one of the best FFIs I've ever seen; calling C code from Haskell is quite trivial, and you can write all of the necessary wrapper code and objects (such as automatic memory management or object destruction) in Haskell using common wrappers. I'd also highly recommend c2hs for writing new wrapper libraries.

lucian1900 13y ago
Part of the problem is that iOS APIs tend to be Objective-C, which is somewhat harder to wrap in Haskell.
- gregschlom 13y ago
  Not really, it's quite easy to call Objective-C methods (or more correctly, to send messages to Objective-C selectors) and perform other Objective-C-related tasks from C. See: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html https://developer.apple.com/library/mac/documentation/Cocoa/... This is actually what the Objective-C compiler does. It translates your Objective-C code to C method calls.
  - chc 13y ago
    It's not that easy. I mean, just sending a message could entail one of objc_msgSend, obj_msgSend_stret or objc_msgSend_fpret, and which one you want to use is not always as clear-cut as you might prefer (http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_explain_objc_msgSend_stret.html http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_e...). And then there's the hassle of defining classes dynamically, which entails six function calls just to create a class with one empty method, and one of those essential functions is not actually provided for you AFAIK unless you're using Apple's compiler where it's a builtin, so you'll need to write it yourself. It's not ridiculously hard, but it's somewhat less easy than normal C FFI.
    - iand675 13y ago
      The other hard part about it is that Haskell's FFI doesn't support variadic functions in a friendly way, which makes argument passing that much trickier.
      - chc 13y ago
        There is a similar problem with objc_msgSend in C: Methods with certain argument types can't be called with a normal objc_msgSend(). Instead, you need to create a specifically typed function pointer and assign objc_msgSend to it. I think a similar solution would be necessary with Haskell.
        iand675 13y ago
        I'd appreciate seeing a link to an example of this. I put a decent amount of work (a few years ago) into writing some bindings in Haskell to the objc runtime, but ended up shelving it until I could come up with a satisfactory solution to the variadic function dilemma.
        chc 13y ago
        Here are a couple of Stack Overflow answers that illustrate how you do it in Objective-C: http://stackoverflow.com/a/2573949 http://stackoverflow.com/a/2573949 http://stackoverflow.com/a/18689338 http://stackoverflow.com/a/18689338 If you're interested in the nitty-gritty of how objc_msgSend works, bbum from Apple wrote up a great low-level walkthrough a few years back: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/ http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-th...
      - JoshTriplett 13y ago
        If you just need to call variadic functions with a specific parameter list determined at compile time, that's easy with the existing FFI; just write a prototype for the function for any given set of arguments you want to call it with. (For instance, you can have an FFI binding printf_int_float :: CString -> CInt -> CFloat -> IO CInt .) If you really need to construct calls at runtime and you don't know the argument list at compile time, there's a Haskell binding to libffi. However, you generally only need that if you're writing a language interpreter or similar.
dbaupp 13y ago
Doesn't calling C code interact poorly with green threading? (I assume that handlers that make it act slightly sanely exist, but I imagine the cost of setting up native threads for FFI is rather high.)
- chowells 13y ago
  Native threads for FFI calls are pooled. It's not cheap, but it's not too expensive either.

chc 13y ago

I think the idea is that you would use the standard tools for the edges of the program with a Haskell core underneath handling the thinky bits. (I have no experience at all doing this, but it seems like the natural use case.)