Hacker News Reader

Comment by Osmium | Hacker News Reader

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

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

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?

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.

Part of the problem is that iOS APIs tend to be Objective-C, which is somewhat harder to wrap in Haskell.

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/...

This is actually what the Objective-C compiler does. It translates your Objective-C code to C method calls.

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_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.

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.

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.

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.

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/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-th...

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.

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.)

Native threads for FFI calls are pooled. It's not cheap, but it's not too expensive either.

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.)

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...

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.

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?

(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.)

I'll be giving a workshop on using GHC iOS at BayHac 2014 [1] along with a demo of http://tree.is which is built entirely on top of it!

[1] http://www.haskell.org/haskellwiki/BayHac2014

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

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/CrossCompilin...

"In particular, GHC now has all the necessary patches to support cross compilation to Apple iOS, using the LLVM backend."

Reply on news.ycombinator.com