[Openmcl-devel] ClozureCL on iPhone

[Gary Byers]

On Mon, 31 Oct 2011, Andrew Shalit wrote:

[...]

> There are a few ways that I could see CCL running iOS
>
> 1. We could take the Gambit Scheme approach and compile to C.  You give up most interactive development.

> 2. We could write a full Common Lisp interpreter.  I don't know
> whether anyone has ever actually done that.  It's pretty easy to
> call 'compile' and modern Common Lisp has lots of special forms.
> But it could certainly be done.

I think that it's probably true that more CL implementations have full CL
interpreters than don't.  MCL had one (that early versions of OpenMCL/CCL
inherited) that basically existed to support STEP; I don't think that people
intentionally ran interpreted code for any other reason (it was just too slow
to be practical), but some implemetations' interpreters are intended to be
used, and people who use those implementations may do at least the early stages
of development without explicitly invoking the compiler.

That's just nit-picking, though.  The fact that you -could- work around iOS
restrictions by running interpreted code doesn't mean that anyone would necessarily
want to do so or that it makes more sense than it does otherwise to implement a
full-blown evaluator/interpreter in CCL.


> 3. We could write a cross-compiler which runs on the Mac, and sends
> iOS code across the Xcode wire to the device. This would be a big
> project.

> 4. We could write a CCL development environment that runs on
> jailbroken iOS devices and supports delivery on non-jailbroken
> devices.  This is legal, but it's not reliable and Apple would
> likely frown on it.


I haven't actually jailbroken an iDevice in a year or so.  I never experienced
any reliability problems that were related to jailbreaking and haven't heard
of any (to the extent that I've tried to follow things) in the last year.

It's certainly possible to install lots of things (UI hacks) on a
jailbroken device and certainly possible that some of those things
could introduce stability problems, but I don't know that removing the
code-signing requirement (jailbreaking in and of itself) has any negative
effect on stability, and there are Cydia packages that fix some of the
horrifying iOS security holes (including those that were used by the
jailbreaking process itself.)

Some people may care whether or not Apple would frown at them if they
jailbroke their devices.  I personally like to frown at such people, but
have to confess that all of this frowning doesn't seem to affect much of
anything.  Some people or organizations may have real (or imagined) reasons
for not wanting to jailbreak their devices, but I don't think that any
of the other approaches discussed here are particularly viable.

At this moment, jailbreaking recent versions of iOS (4.3.5 and 5.0)
is a little less attractive than it was for earlier versions. (The
device is left in a state where it can't boot unless it's connected
("tethered") to a Mac or PC running a special utility.  Untethered
jailbreaks for these newer iOS versions are supposedly due Real Soon
Now, but the cat-and-mouse game that Andrew mentioned comes into play.
(One side-effect of releasing a jailbreaking utility that exploits an
iOS security hole is that doing so increases the chance that the hole
will be fixed in the next iOS update.)

It's hard not to frown when thinking about all of this.  (Personally,
I try to face Cupertino while doing so.)


> I believe that any of these are possible, but none of them are
> things that we want to do on our own time.  We'd be happy to talk to
> anyone who wanted to fund this work.  We'd also like to be able to
> use CCL to write iOS apps.

I had CCL running on a jailbroken iPad a year or so ago.  Once the thrill
of defining and running FACT on an iPad wore off, it was pretty clear that
there was a lot of work to be done before we could really talk about developing
in CCL on and for an iDevice, and no real iOS-specific work has been done
in the last year.

> Andrew
>