4 ms·

I'm intrigued by "full iOS support." Does this mean it's now possible to write iOS apps using a Haskell backend?

• SmileyKeith 13y ago
  Assuming it has something to do with this[0] but I'd be interested to know as well. [0]: https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompilin...
• sigzero 13y ago
  "In particular, GHC now has all the necessary patches to support cross compilation to Apple iOS, using the LLVM backend."
• thinkpad20 13y ago
  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.
              • 13y ago
    • 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.)
• efnx 13y ago
  Yes - you can now compile Haskell code to run on iOS. There are still a few unusual steps that involve ffi but its pretty easy to get a trivial project up and running. I have an unfinished project that shows the process. https://github.com/schell/blocks https://github.com/schell/blocks
• carterschonwald 13y ago
  Yes. Everything but certain naive use of template Haskell or use of ghci is supported for targeting IOS. There's also some related engineering to provide android support
• icetortoise 13y ago
  While this is nice, it results in a big static lib(27M) to include in your app. This might be okey for some games, but maybe not for small apps. I was very interested in a Haskell app, but eventually gave up because of this...
  • maxpow4h 13y ago
    the twitter app is 30M, we have already past the point of sensible app sizes. edit: fb messenger is 60M, a ghc-ios app with the elm compiler baked in is 24M.
    • tvon 13y ago
      To me that makes it clear that a minimum size of over 20M is a serious problem. How crazy would it be if the Twitter app was over 50M, or Facebook Messenger over 80M?
      • tvon 13y ago
        (I should not have said "serious problem", I should have said "notable barrier to adoption." That people have made this possible at all is fantastic.)
• lukexi 13y ago
  I'll be giving a workshop on using GHC iOS at BayHac 2014 [1] along with a demo of http://tree.is http://tree.is which is built entirely on top of it! [1] http://www.haskell.org/haskellwiki/BayHac2014 http://www.haskell.org/haskellwiki/BayHac2014