Writing apps for the iPhone in Scheme(jlongster.com)
jlongster.com
Writing apps for the iPhone in Scheme
http://jlongster.com/blog/2009/06/17/write-apps-iphone-scheme/
14 comments
Also check out http://programming.nu/.
It's a sort of S-expression-based functional language that leverages the Objective-C runtime.
It's a sort of S-expression-based functional language that leverages the Objective-C runtime.
Doesn't Apple frown on VM's and/or embedded interpreters in the iPhone submissions? Couldn't the presence of Scheme's eval function ( whether it's exposed to the user of the compiled software or not ) end up being an issue?
I commented on that near the end. You can compile Gambit without EVAL.
Also, supposedly there are apps out there which have embedded Lua. You just aren't allowed to download new code.
Also, supposedly there are apps out there which have embedded Lua. You just aren't allowed to download new code.
While this is a very cool hack, compiling to C is (relatively) easy. Objective-C, but mostly the (Cocoa Touch) API's are the interesting bit of iPhone development. Until there is a good way to use those API's in a high(er) level language, I'd stick with Objective-C :)
This is really cool as I'm in the process of working my way through SICP (though painfully but learning), I was wondering if I could really use Scheme for real world usage. This seems to be the most likely answer.
Real-world usage is where Scheme and most Lisp dialects really shine, specially when you're not fighting against the deployment platform. I say that because this Scheme on iPhone hack has a lot of GCCisms, shell fudging and other not-too-lispy kludges. The day you have a Scheme repl with nice bindings for the system libraries is the day the fun begins ;-) it almost feels like cheating; you do things on the system live, where others have to cross compile and upload it :-)
Hold on now, this isn't a hack :) It's a full Scheme implementation compiled to C and then compiled for the iPhone.
And once you get this far, it's easy to compile in the Scheme system, but load all of your code at runtime and edit it live. I'm going to add a remote REPL for debugging which will let you attach a REPL to a running app the iPhone, for example.
Maybe my blog posts on that will be more of the real world you are looking for!
And once you get this far, it's easy to compile in the Scheme system, but load all of your code at runtime and edit it live. I'm going to add a remote REPL for debugging which will let you attach a REPL to a running app the iPhone, for example.
Maybe my blog posts on that will be more of the real world you are looking for!
Any idea if you can actually get an iPhone app published this way? Usually the code generated from one of these high->low level compilers is tough to read and nearly impossible to understand. If it hasn't already done so, I imagine that Apple might bar submissions with obfuscated code[1], and it can be argued that the resulting code produced by the Scheme to C compilation is obfuscated and therefore ineligible for App Store inclusion.
[1] I was operating under the assumption that the source, not a binary, was provided to Apple. I stand corrected.
[1] I was operating under the assumption that the source, not a binary, was provided to Apple. I stand corrected.
There are apps built with C# (via Mono and the Unity3D game development tool).
"de Icaza identifies almost 40 applications (most of which are games) in Apple's App Store that are built on Unity and Mono...Mono's robust portability and advanced support for features like static compilation are enabling developers to use it in innovative ways that wouldn't be possible with Microsoft's .NET implementation"
http://arstechnica.com/open-source/news/2009/01/open-source-...
"de Icaza identifies almost 40 applications (most of which are games) in Apple's App Store that are built on Unity and Mono...Mono's robust portability and advanced support for features like static compilation are enabling developers to use it in innovative ways that wouldn't be possible with Microsoft's .NET implementation"
http://arstechnica.com/open-source/news/2009/01/open-source-...
You submit a binary to the app store, not source code.
Oh, OK, good to know. The article made it sound like using Objective-C was a requirement for developing for the iPhone, and the only reason I could see for that to be the case is if they needed the source code. That said, why not just target the architecture directly? Why make a pit-stop at C?
>Why make a pit-stop at C?
Optimizing C compilers and platform independence properly. There have been a lot of research involved in making C compilers very fast, so you get to copy that for free.
Optimizing C compilers and platform independence properly. There have been a lot of research involved in making C compilers very fast, so you get to copy that for free.
Objective-C is required the same way Java is required for the Android. You could skip to assembly, but then you miss out on all the Cocoa Touch APIs.
Also, Gambit Scheme is a generic system designed to target C so that it can compile to all kinds of architectures. It's a mature, robust system that comes with a lot of stuff.
Also, Gambit Scheme is a generic system designed to target C so that it can compile to all kinds of architectures. It's a mature, robust system that comes with a lot of stuff.
There was a recent post on HN about compiling various dynamic languages to C (I've lost the link). Of particular interest to me was JavaScript. For writing js code targeting the iPhone, PhoneGap and Appcelerator Titanium are cool, but still feel a bit gimped for doing truly native non-cross-platform stuff.