I'm going to withhold my excitement until I get proof that Apple will approve GHC compiled binaries.
iPhone, meet Haskell
21–30 of 53 posts
Re: iPhone, meet Haskell
#22Wow, 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?
Howdy! 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…
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?
Re: iPhone, meet Haskell
#23I'm going to withhold my excitement until I get proof that Apple will approve GHC compiled binaries.
A formal proof? ;-)
Re: iPhone, meet Haskell
#24I'm going to withhold my excitement until I get proof that Apple will approve GHC compiled binaries.
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.
Re: iPhone, meet Haskell
#25Earlier quoted context omitted.
Howdy! 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…
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?
totally unrelated, I think. :)
Re: iPhone, meet Haskell
#26I'm going to withhold my excitement until I get proof that Apple will approve GHC compiled binaries.
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.
Re: iPhone, meet Haskell
#27I'm going to withhold my excitement until I get proof that Apple will approve GHC compiled binaries.
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 :)
Re: iPhone, meet Haskell
#28Anybody 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.)
Re: iPhone, meet Haskell
#29I'm going to withhold my excitement until I get proof that Apple will approve GHC compiled binaries.
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. T…
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.
Re: iPhone, meet Haskell
#30Earlier quoted context omitted.
Apple wouldn't permit this in the AppStore
Sure they would. http://omz-software.com/pythonista/ http://omz-software.com/editorial/ http://twolivesleft.com/Codea/ 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.
I thought those were running interpreters via javascript. User-generated code is really okay?