I've been using https://github.com/jspahrsummers/ObjectiveHaskell/ as my bridge between the two worlds (with some modifications for iOS that I'll be posting soon). Haskell has a wonderful FFI that lets you easily call C/Objective-C from Haskell and vice versa.
There's also Manuel Chakravarty's extremely exciting "Inline Objective-C" project (coming soon) that allows you to embed Objective-C code directly into Haskell, which would make it nearly effortless to speak fluently with Apple's frameworks.
There are tons of awesome Haskell FRP implementations, from Netwire to Elerea to Reactive-Banana:
It would also be a lot of fun to get Helm running on iOS once they finish their OpenGL backend.
I definitely couldn't have pulled off my own project (SpaceTime, a multiplayer app engine for iOS; announcement soon) without Haskell. I've been using the development versions of GHC iOS to build it for over a year and it's been a joy.
I will support a crowdfunding campaign.
(There may be some clever way to modify how GHCI works to change that, but offhand, its not obvious to me what that would be)
You just can't have an app that downloads external code and then runs it; if all of the code that gets run is prepackaged in the app bundle or user-generated then it's absolutely fine.
Yes, but they may do so only by embedding Apple's own sandboxed WebKit component. So the downloading, execution, and results are tightly controlled.
I'm sure I've seen a Lua environment like this.
That said, have fun and try things out! Share what you learn, and either way, it'll be time enjoyably spent.
Would it be possible to drop a cross compiled Haskell library into a Xamarin project and call into it from the .Net (F#) world? That would be the killer feature for me!
Also not much mention of android here - is it possible to target android with Haskell at the moment?
Joey Hess has been using it to build git-annex for Android.
And much of the work we did simply improved support for cross-compilation in general, so Android support should be better than ever! : )
I strongly recommend using standard haskell binary distributions, such as those prepared by GHC HQ, or the Haskell Platform folks, or perhaps any brew Tap that Darin Morrison or Luke Ianni author. Do not use brew for haskell tools (at least until they actually follow Darin Morrison's word to the T, because they do janky stuff for haskell.)
And while the stability of GHC/Haskell Platform was indeed questionable during 2012.2.0.0 and the beginning of 2012.4.0.0, they cleaned it up as time went along and I haven't noticed any issues with it for the past 4 or 5 months. You make a comment below about Haskell Platform being associated with specific GHC releases, and AFAIK Homebrew actually freezes GHC at versions compatible with the current release of Haskell Platform now. The reason I prefer to use the package manager instead of the pre-distributed binaries is because it provides for a deterministic and (theoretically) testable/repeatable upgrade path.
I started with haskell-platform from brew and ended up with a broken ghc build.
"inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o
/usr/local/bin/llc: : error: unable to get target for 'arm-apple-darwin10', see --version and --triple.
make: * [rts/dist/build/Apply.o] Error 1
I am starting over with the binary GHC distribution.
Haskell platform is tied to very very specific GHC releases, and have specially prepared and tested installers for each major OS target. Brew throws this all away and treats it like a simplistic "nice things" wrapper, when in fact its actually 1+ months of engineering time a year for Mark Lenctzer (and a handful of others) to make sure that everything JUST WORKS™ for new haskellers when they install GHC and tools on a machine.
also, for near term sanity, stick to Xcode 4.6 if you're using GHC 7.6
Without some hacky tricks i'm going to help the haskell platform folks work out, GHC 7.8 is the only GHC version that will play nice with OS X mavericks/Xcode 5. Hopefully with the tricks Luke Iannini and I have cooked up, GHC 7.6 in this fall's Haskell Platform release will work very nicely on Mavericks / Xcode 5. (but it will have to be a different haskell platform install than for systems pre Xcode 5)
This will be part of the upcoming GHC 7.8 release spectacular, at which point we'll release binaries and brew formulas!
(we'll also likely release some test binaries sooner than that if you're impatient :), stay tuned)
Worry about the normal reasons for getting an app rejected :)
its also worth noting that XCode 5 (as of Dev Preview 5 or 6) has some patches backported from Clang HEAD via the Clang 3.3 Point release that fix bugs that have only ever been triggered by GHC, namely http://llvm.org/bugs/show_bug.cgi?id=16371 and http://llvm.org/bugs/show_bug.cgi?id=16363
(and I'm incredibly grateful to the engineers who work on Clang for helping get those patches backported to the pending Clang 3.3 bugfix release, and thence to apple Clang, I owe them all a beer or something like that)
I think Apple, as a business, wants every community of smart Developers to write amazing, profitable applications for their Desktop and Mobile ecosystems. Haskell targeting iOS immediately grows the pool of smart developers who might write iOS applications, and hopefully also just make writing certain very interesting applications much less painful! This is exciting!
tl;dr the latest xcode 5 Apple Clang dev previews have backported patches from Clang HEAD fixing bugs only ever triggered by GHC. Interpret that however you please :)
In fact, I did a quick Google search before submitting this reply. Relevant quote, from an Apple press release in 2010:
> In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.
Furthermore iPhone apps are definitely allowed to embed interpreters (caveat: no JITC's) and run scripts included with the binary or downloaded as part of an in-app purchase.
Compiling to ARM and then running on the device is perfectly fine with Apple.