5 ms·

What do you mean "Apple won't let it"? Who's stopping you? Just from Google I found https://wukix.com/mocl https://wukix.com/mocl for example.

by jolux 9y ago

dreamcompiler 9y ago
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. https://www.google.com/amp/s/amp.reddit.com/r/lisp/comments/6jlwxt/mocl_lisp_on_mobile/ https://www.google.com/amp/s/amp.reddit.com/r/lisp/comments/...
- jolux 9y ago
  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.
  - kgwgk 9y ago
    He said "full-blown", didn't he?
  - yorwba 9y ago
    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 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 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.
    - lispm 9y ago
      > 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.
      - dreamcompiler 9y ago
        > 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.
    - jolux 9y ago
      >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.
aidenn0 9y ago
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.
- jolux 9y ago
  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.
  - rvense 9y ago
    That's not the issue here. They're talking about running the compiler itself on the device. Apple won't let you do that.
- lispm 9y ago
  > 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.
  - aidenn0 9y ago
    LW has always been better at AOTing everything than cmucl derivatives. CCL is somewhat in the middle of the two. That being said, how did I miss LW introducing a version that supports iOS? That's huge!
    - lispm 9y ago
      > 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. LispWorks for Mobile: http://www.lispworks.com/products/lw4mr.html http://www.lispworks.com/products/lw4mr.html

What do you mean "Apple won't let it"? Who's stopping you? Just from Google I found https://wukix.com/mocl https://wukix.com/mocl for example.

by jolux 9y ago

What do you mean "Apple won't let it"? Who's stopping you? Just from Google I found https://wukix.com/mocl https://wukix.com/mocl for example.

dreamcompiler 9y ago

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. https://www.google.com/amp/s/amp.reddit.com/r/lisp/comments/6jlwxt/mocl_lisp_on_mobile/ https://www.google.com/amp/s/amp.reddit.com/r/lisp/comments/...

jolux 9y ago
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.
- kgwgk 9y ago
  He said "full-blown", didn't he?
- yorwba 9y ago
  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 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 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.
  - lispm 9y ago
    > 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.
    - dreamcompiler 9y ago
      > 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.
  - jolux 9y ago
    >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.

aidenn0 9y ago

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.

jolux 9y ago
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.
- rvense 9y ago
  That's not the issue here. They're talking about running the compiler itself on the device. Apple won't let you do that.
lispm 9y ago
> 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.
- aidenn0 9y ago
  LW has always been better at AOTing everything than cmucl derivatives. CCL is somewhat in the middle of the two. That being said, how did I miss LW introducing a version that supports iOS? That's huge!
  - lispm 9y ago
    > 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. LispWorks for Mobile: http://www.lispworks.com/products/lw4mr.html http://www.lispworks.com/products/lw4mr.html