Dylan was a slimmed-down Common Lisp. I thought it was a pretty good idea at the time but when they dumbed down the syntax (removed the parentheses) I lost interest. It's ironic that full-blown Common Lisp could easily run on iphones today but Apple won't let it.
Mocl is a subset of Common Lisp and cannot do the same things on ios that a full CL (like SBCL or CCL) can do on MacOS. It's intended to be a "waterfall model" code generator where code is compiled strictly in advance. Obviously this is how most other languages work, but one of the distinguishing features of CL is the ability to compile new code opportunistically at run time. This is impossible on ios because Apple won't allow it. There are a few other issues with mocl that make it seem like a second-class language to me, coming from using first-class CLs on MacOS. I'm sure mocl is fine if you're comfortable with these compromises; I'm not.
Of course it's a second-class language, so are React Native and everything else that isn't Objective-C or Swift. But that's not what you said, you said they wouldn't allow it. If you want them to actually support it and make it a native option that's entirely different.
I'm not sure you understand. Common Lisp has lots of dynamic features that conflict with Apple's guidelines. For example, the ability to compile code at runtime is part of the language: http://phoe.tymoon.eu/clus/doku.php?id=cl:functions:compile
React Native is only able to get around this by using Webkit's JavaScript engine.
I couldn't find any documentation of mocl features, but it seems like they neuter parts of the language that wouldn't pass the app store review: https://wukix.com/support/ticket/84
As you can see in that support ticket, this means that standard-conforming CL code doesn't run unmodified.
> For example, the ability to compile code at runtime is part of the language
An actual Common Lisp implementation does not need to support 'compile' for the application, when it is not needed at runtime. Actually if the CL implementation is only an Interpreter, then COMPILE is a no-op.
Take for example LispWorks, they have a compiler which creates an iOS library which is linked into an Xcode iOS application. When you 'deliver' (means: creating shippable code) the Lisp system removes the compiler (and potentially all kinds of other stuff). Generally the Common Lisp compiler/runtime to iOS/ARM code supports the whole language, without the runtime compiler.
This 'Delivery' tool is also used on other platforms, not just for iOS.
You must abstract a bit from what the language standard describes and what actual implementations do or support. If somebody wants to deliver static/restricted applications with Common Lisp, then he/she would just use a Common Lisp system which can do that, regardless of what the standard says or requires.
> You must abstract a bit from what the language standard describes and what actual implementations do or support.
Fair enough. I don't actually use #'compile all that much in my code. But I've been burned by these compromised pseudo-Lisps so much in the past that I tend not to trust them. And I wasn't aware that Lispworks had an ios solution; I'll check it out. Thanks.
>As you can see in that support ticket, this means that standard-conforming CL code doesn't run unmodified.
Perhaps not in Mocl, but my point was not that Mocl specifically was a good idea and was fully functional, but that implementations for these languages do exist and do work at least to some extent. I found Mocl by googling "Common Lisp iOS." I am not a Common Lisp programmer. I just know that a lot of non-native languages support compiling for iOS these days, and I honestly would have been a bit surprised if Common Lisp didn't. Plus, your child even seems to suggest that "standard-conforming CL code [can't] run unmodified" is not true.
Most performant CL implementations require the ability compile to executable code at run-time. iOS disallows executing from the heap for security purposes, so porting those implementations is a non-starter.
Others have said this already, but mocl is a (large) subset of common lisp that requires all code for which performance matters to be AOT compiled. It's better than nothing, but it lacks the level of dynamicism that lispers have come to expect.
> Most performant CL implementations require the ability compile to executable code at run-time.
Not really. Most performant CL implementations make sure that at runtime nothing needs an actual compiler, unless the application actually needs it.
For example the LispWorks on iOS implementation supports the whole Common Lisp, minus the runtime compiler. It's still possible to use the interpreter, though - AFAIK.
> LW introducing a version that supports iOS? That's huge!
That's a delivery compiler with a relatively complete LispWorks runtime, minus the runtime compiler. It's a bit expensive. It lacks any GUI and is supposed to be used inside an Xcode iOS application.
There is also one for Android...
They are working on the 64bit ARM version. The 32bit ARM version is out for some time.
I don't know much about Common Lisp, all I know is that some people still think Apple only allows apps written in directly supported languages, which hasn't been the policy in years.
They apparently loosened the restrictions on developer tools. For example, I used to have a Scheme interpreter on my iPhone. The problem is that you can't set the executable bit on a memory page, so you can't compile a form to native code and then execute it. You can still have an interpreter, or a byte-code compiler plus a byte-code interpreter, but you lose lisp's ability to compile and run native code. As others have said in this thread, there are workarounds for that, since most lisp applications don't need it, but there's no real reason, other than politics, and a misguided security policy, to forbid it.
