[Openmcl-devel] Mac App store: will CCL apps fly?

[Gary Byers]

If CCL (the name changed a few years ago ...) or "something like it"
is using "undocumented APIs", I wish that someone would tell me.

I think that the code in the ObjC bridge that enables a command-line
application to connect to the window server and become a GUI
application used to be based on something that I'd reverse-engineered
somehow, and I was always worried that some OS release would break it.
Someone eventually pointed out that there was a documented, public
way to do that and we started using that documented, public mechanism.
Why on earth wouldn't we ?

CCL certainly does a lot of things (its own memory memory management
and exception handling) that most C/ObjC applications don't do or
don't do directly, and I was serious when I said last week that many
of those things are poorly documented.  I think that there's a difference
between using mmap() or sigaction() or catch_exception_raise() and using
SecretApplePrivateThingThatMayDisappearSoon(); the latter is an (imaginary)
private function, whereas the others are entirely public.

I think that on x86 Darwin we sometimes return from a signal handler via
a direct system call and the ObjC bridge on 32-bit Darwin contains code
that knows too much about the internals of a jmp_buf structure.  It'd
be great if there were public ways of doing these things, but I'm not
holding my breath waiting for that to happen.  If there are other cases
where CCL knows too much about opaque, private things, I can't think of
any and I'd have to assume that the number of such cases is very, very
small.

You can get a ~99% accurate idea of what [Obj]C functions/methods a
CCL program calls just by grepping for the FFI reader macros (#_, #/)
in its sources, and the other ~1% isn't much harder.  (The percentages
might vary a bit if things like CFFI introduce wrappers, but there is
a finite and likely small set of things to grep for.)  It might in
fact be easier to determine whether or not a CCL program uses "private
APIs" than to make that determination for a typical ObjC program.  (I
have no idea whether or not that's in fact true, but I think that it's
at least plausible that it is.)  It'd probably be pretty stupid to
start saying "CCL programs are more likely to be approved because it's
easier to determine that they don't call private APIs"; I don't think
that it's a whole lot more useful to say "CCL programs are unlikely
to be approved because of an imaginary widespread use of undocumented
or private funtionality."

On Mon, 25 Oct 2010, Brian Mastenbrook wrote:

> On 10/25/2010 05:11 PM, Daniel Weinreb wrote:
>> I'm just back from the Int'l Lisp Conference.  Go to the App Store
>> and download Farmageddon for your iPhone. It is a cute, silly
>> game featuring ducks, geese, and, yes, cows.
>> 
>> And it's written entirely in Gambit Scheme.
>
> There are other Gambit apps on the store too. The difference between Gambit 
> and OpenMCL here is that Gambit compiles the Scheme code into C, which means 
> that it's less likely to use "undocumented" APIs than something like OpenMCL. 
> Note that Apple is actually using static analysis tools for the iPhone app 
> store to enforce that restriction.
>
> I expect that someone could use ECL to write apps in Common Lisp for the 
> Apple app stores today, though I'm not aware of any apps on the store written 
> this way.
>
> -- 
> Brian Mastenbrook
> brian at mastenbrook.net
> http://brian.mastenbrook.net/
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>