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.

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.

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.