Hacker News Reader

Comment by eru | Hacker News Reader

Doesn't Apple still forbid programs written in anything apart from Objective C, JavaScript (and a third language, that I don't remember)?

View on HN

Nope, not anymore. http://daringfireball.net/2010/09/app_store_guidelines

Knowing the Haskell community, they could probably convert GHC Core into idiomatic Objective-C if they really wanted to, but it's not necessary. RubyMotion and other platforms are accepted because they stick to Apple's guidelines. The same would go for a GHC-iPhone platform.

iPhone Monad, anyone?

Why would one need to, GHC can already compile Haskell/Core to C? But as you say, it's not a violation of Apple's terms anymore.

Because compiling to C would be too easy.

The guidelines say nothing about any particular programming languages.

You can always compile scheme / haskell etc to C and then use it as a library. (gambit-scheme users do this).

Indeed. I did this with one program: I wrote some number crunching code in Haskell, and exposed some functions to C via the FFI. Then I wrote the user interface in Cocoa/Objective-C. The primary thing that requires some though is how to pass data between C and Haskell. You usually end up marshaling/unmarshaling some structs:

http://www.haskell.org/haskellwiki/FFICookBook#Working_with_...

Sounds quite interesting. Do you have a write up about this anywhere? Is the gain rom Haskell worth the impedance mismatch of cross communication?

Do you have a write up about this anywhere?

I used the following references:

http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ffi-g...

http://weblog.haskell.cz/pivnik/building-a-shared-library-in...

I have just put up a small-ish example using my approx-rand-test package (which implements approximate randomization tests):

https://github.com/danieldk/haskell-library-example/

Is the gain rom Haskell worth the impedance mismatch of cross communication?

I guess it depends on how much you love Haskell ;), and the usage scenario. I think using Haskell's FFI in this direction is especially attractive if you prefer to write most code in Haskell, but need some functionality that does not map naturally to a pure functional language (such as GUIs in Cocoa). If you want to mix a lot of imperative and functional code seamlessly, F#/C# or Scala/Java are probably better options.

Thanks what's the size like? The last time I built a Haskell application it was quite large. This is more of an issue for mobile apps.

FWIW I've done Scala/Java+Android and WP7+C#/F#, interestingly Wp7 is by far the easiest mobile to get a good functional language running on.

Thanks what's the size like? The last time I built a Haskell application it was quite large.

4969KB with the runtime and package dependencies linked in the dynamic library (Darwin, 64-bit). Since I do not have dynamic libraries of its dependencies installed, I cannot quickly try a completely dynamic version...

interestingly Wp7 is by far the easiest mobile to get a good functional language running on.

I purchased a Windows Phone last week (iOS user here) to see how it works, and I am surprised how good the integration is.

In theory, yes. In practice, no. The C emitted from compilers is usually an awful mess that looks like Assembly code and it might not have sane function entry points so it could be used as a library. Then you need to get the runtime system (garbage collector, etc) up and running to run your code. It's by no means impossible but it's very impractical.

Historically, C was used to implement many (functional) programming languages because it provided a convenient compiler back end and a well-defined intermediate representation between the front end and the back end. Not because you could compile to C and use your code from C.

Fortunately, GHC can build shared libraries on some platforms, which makes it fairly easy to expose Haskell functions to C:

- Using the FFI one can specify foreign exports.

- The runtime and garbage collector can be initialized/deinitialized by adding an object file that uses gcc's constructor/destructor attributes.

- Multiple calls to hs_init (one for each library) are allowed, as long as they are balanced by hs_exits.

- It's ok to have multiple root modules.

Indeed, the FFI in GHC is one of the best ones out there. It makes it convenient to call C from Haskell and vice versa(!). I wish every language had an FFI and RTS that good!

No.

Reply on news.ycombinator.com