Wow, this looks super interesting. Would this be the first step in creating a Haskell wrapper for doing native UI work, or is it more useful for games and the like?
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.
https://gist.github.com/mchakravarty/4632567
It would also be a lot of fun to get Helm running on iOS once they finish their OpenGL backend.
http://helm-engine.org
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.
Also: Luke's SpaceTime is super exciting, he told me a teeny bit about it a few weeks ago. Should be seriously exciting for any ios dev who is writing collaboration tools
Is it related to Fujimoto et al's space-time memory? There was also a project called Stampede that that used a similar name to mean something completely different. Or is it just a name?
That would be nice... and remember, Carmack mentioned that he felt guilty about not doing "real work" when he was doing Haskell, but because there was Lisp on his iWhatever, he could play with Lisp when he couldn't get to his main computer to do "real work", so spent more time on Lisp.
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.
This is interesting. I've been keen on experimenting with FRP for a while, and now I can use it for 'real world' stuff on a platform I know I just might have the push I need to jump into Haskell.
please note: FRP is an idea, and while theres some interesting tools out there for FRP, it is not always the right solution, and in many respects, "FRP done Right" is still an open research problem.
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?
Anybody here know, off the cuff, if the GHC packaged in Homebrew is compiled correctly to utilize the wrapper scripts out of the box, or if I'd need to build the cross-compiler myself as described in the linked documentation?
Nope. I also strongly recommend against using the normal "brew" formulas for haskell tools, its only by PROACTIVE efforts by mac using haskellers that the standard brew aren't a complete disaster (or at least, wont' be a disaster, soonish).
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.)
Hmm. Well, looking at the Github repo activity, Darin is actively involved in the GHC formulae these days. In fact he's actively involved in getting Homebrew's GHC formula prepped for OS X Mavericks, which you note as an upcoming issue below. So that's encouraging.
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.
1) you can very easily have multiple ghc's installed and have them not clobber each other
2) use the binary packages if you want a default that just works. If you look at the relevant ghc ticket on brew, they're very keen on modifying the formulae against the recommendations of Darin very very easily.
3) I use brew for many things, and even donated quite a bit to their kickstarter, but I do not trust brew to do Haskell right.
yeah, the brew folks don't understand the point of haskell platform, and honestly botch it. Their GHC formula should have something like ---add-Haskell-Platform-if-this-version-has-it (but a shorted name for it), because haskell platform is tied to specific GHC versions, rather than as another brew formula/package.
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)
You need to build it yourself at the moment since this just went into GHC HEAD. Feel free to ask me on Twitter if you need any help (@lukexi), it's pretty easy.
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)
Finally a chance to learn Haskell and iOS development at the same time! Will I be able to do this all from a Linux machine or do I still need Apple hardware?
Apple already approves applications written using the Xamarin tools (C#/F# compiled with LLVM), and RubyMotion. They are ok with other tools. Haskell is a more compiled language than any of F#, C# or RubyMotion (if thats even possible). There is no reason to worry about that.
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 :)
What would prevent them? Didn't they relax the cross-compile restrictions like, 3 years ago? Adobe has a cross-compiler, that I know for sure.
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.
At least one of Ruby Motion or Xamarin Studio is compiling source code into iPhone apps.
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.
They won't have a problem with it, I'd bet on it. That's not their concern really at all - the people who look at confirming apps look at human interface guidelines, functionality, crashes (although we've had an app that doesn't even launch it just crashes everytime approved), and if it meets their guidelines.
There now are many interpreted as well as compiled non Objective-C languages around; from .NET languages to Object Pascal, Ruby, Java, Lua, Python, Javascript and others used to create iOS applications and they all are happily allowed in the Appstore. You are just not allowed to dynamically load 'new code' from servers and execute it on the device unless it's via the Safari Javascript engine.
Compiling to ARM and then running on the device is perfectly fine with Apple.
