I'm developing a Lispworks application
for reading text with theatrical intonation
that would be great on an iPhone.
I'm excited to do this, but the part that computes
intonation consists of about 2 MB of lisp code.
Is there any hope that a Lisp compiler
would ever run on the iPhone,
like Unity C#/Javascript does?
Or should I try to use Kyoto,
GNU or ECL cross-compilers to C?
-- Lawrence Au
www.sauriel.com
On May 14, 2009, at 8:45 AM, Lawrence Au wrote: > I'm developing a Lispworks application > for reading text with theatrical intonation > that would be great on an iPhone. > > I'm excited to do this, but the part that computes > intonation consists of about 2 MB of lisp code. > Is there any hope that a Lisp compiler > would ever run on the iPhone, > like Unity C#/Javascript does? > > Or should I try to use Kyoto, > GNU or ECL cross-compilers to C? If you're talking about an Apple sanctioned app (as opposed to an app for jailbroken iPhones) then I'm pretty sure the IPhone developer agreement prohibits the use of interpreters. If this is what you're aiming for, you'd need a lisp->C/Objective-C translator. Maybe ecl would not be frowned on by Apple? regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro@mac.com
On May 14, 2009, at 1:11 PM, Rainer Joswig wrote: > A compiled and 'delivered' Lisp application without the functions > COMPILE and EVAL would not be an 'interpreter' based application, > I'd say. Why should Apple reject it? Apple's no-interpreters restriction is fairly inclusive. I found this quote from the iPhone dev agreement on the net: "An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug- in architecture, calling other frameworks, other APIs or otherwise." It's not at all clear to me that Apple would see, for example, the ecl runtime as anything other than a "framework" or "other APIs" whose purpose is to "install or launch other executable code." IOW, Apple pretty clearly wants devs to use Objective-C and Apple's own interpreters (e.g, javascript) and not much else. I don't know if Apple would sanction an ecl based lisp app, but they certainly have the leeway to deny it if they choose to interpret the dev agreement that way. warmest regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro@mac.com
How about Chicken, which would be Scheme rather than CL, but I believe it compiles to C and can be used with XCode? On May 14, 2009, at 6:45 AM, Lawrence Au wrote: > > I'm developing a Lispworks application > for reading text with theatrical intonation > that would be great on an iPhone. > > I'm excited to do this, but the part that computes > intonation consists of about 2 MB of lisp code. > Is there any hope that a Lisp compiler > would ever run on the iPhone, > like Unity C#/Javascript does? > > Or should I try to use Kyoto, > GNU or ECL cross-compilers to C? > > -- Lawrence Au > www.sauriel.com > >
On Thu, May 14, 2009 at 10:53 PM, Raffael Cavallaro <raffaelcavallaro@mac.com> wrote: > Apple's no-interpreters restriction is fairly inclusive. I found this quote > from the iPhone dev agreement on the net: I'm wondering if the situation for Lisp would be comparable to Smalltalk. There are apparently applications running on the Squeak VM available in the App store: "In both cases the Squeak VM is running natively on the iPhone serving pages to a web browser that is displayed on the screen." - http://www.lukas-renggli.ch/blog/iphone-and-seaside - Willem
On May 15, 2009, at 9:56 AM, Willem Broekema wrote: > I'm wondering if the situation for Lisp would be comparable to > Smalltalk. There are apparently applications running on the Squeak VM > available in the App store: It is precisely analogous in that both require a non-apple runtime in order to execute. The problem is that Apple have been inconsistent wrt what they approve and do not approve. Some apps that require a non- apple runtime are approved, some are rejected for using "foreign APIs." So it is an open question as to whether Apple would approve something that requires the ecl runtime, or libchicken, or the gambit runtime, etc. They might even approve one ecl app and not approve another - they've apparently done this with other runtimes. regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro@mac.com