[armedbear-devel] Mixing Java/Lisp abstraction barrier in ABCL implementation
Alessio has nicely [committed an simple implementation of RUN-PROGRAM][1] to help out Faré's request for XCVB. [1]: http://trac.common-lisp.net/armedbear/changeset/13270 As I think most of would rather do things in Lisp than Java were possible, his implementation uses the JAVA package FFI primtives (JCALL, JMETHOD, etc) to manipulate the underlying JVM ProcessBuilder abstraction. When I was mucking around with the PATHNAME work, Ville objected to code that I had written in a similar manner, and I re-wrote my patch in Java. As I understand it his objection stememd from the architectural principle that the core ABCL Lisp is to be written without direct calls to Java classes to maintain the Java/Lisp abstraction barrier. So, theoretically, if all the ABCL primitives written in Java were running on a different JVM (say Dalvik or the CLR), the rest of ABCL would run as well, modulo the compiler. But since getting features like RUN-PROGRAM implemented quickly helps everyone out, maybe we should relax this somehow? Maybe placing such code in a different directory ("org/armedbear/lisp/jvm"?) Or use the CL package system to have a SYSTEM-JVM from which SYSTEM can inherit symbols? Does this architectural principle still make sense? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Sat, Apr 16, 2011 at 7:42 AM, Mark Evenson <evenson@panix.com> wrote:
Alessio has nicely [committed an simple implementation of RUN-PROGRAM][1] to help out Faré's request for XCVB.
Thanks, I was too tired yesterday to do the announcement myself ;)
As I think most of would rather do things in Lisp than Java were possible, his implementation uses the JAVA package FFI primtives (JCALL, JMETHOD, etc) to manipulate the underlying JVM ProcessBuilder abstraction. When I was mucking around with the PATHNAME work, Ville objected to code that I had written in a similar manner, and I re-wrote my patch in Java. As I understand it his objection stememd from the architectural principle that the core ABCL Lisp is to be written without direct calls to Java classes to maintain the Java/Lisp abstraction barrier. So, theoretically, if all the ABCL primitives written in Java were running on a different JVM (say Dalvik or the CLR), the rest of ABCL would run as well, modulo the compiler.
But since getting features like RUN-PROGRAM implemented quickly helps everyone out, maybe we should relax this somehow? Maybe placing such code in a different directory ("org/armedbear/lisp/jvm"?) Or use the CL package system to have a SYSTEM-JVM from which SYSTEM can inherit symbols?
Does this architectural principle still make sense?
Thanks for pointing it out. My opinion: it does make sense for the core ABCL (the CL package + the stuff in the SYSTEM package needed to implement CL). I'm not convinced it makes sense for all extensions which are not essential for the correct functioning of ABCL: the cost of having extra primitives written in Java and code to link the Java and Lisp pieces is relatively high for small extensions and the benefits are, imho, not worth that cost. That said, putting direct jnew, jcall etc. in the middle of Lisp code as I did is, as I now realize, bad style; it's better to have a little functional abstraction - (make-process-builder) rather than (jnew "java.lang.ProcessBuilder") - so that in case you want to port the same feature on a JVM with different standard libraries, you can isolate the conditionalization in a few functions rather than having ugly #+standard-jvm #+dalvik #+whatever spread all over the code. Another matter is the policy of putting everything inside org/armedbear/lisp; I did it out of habit, but it would help to have a more structured directory layout, not just for handling potentially incompatible JVMs, but also (and mainly) to separate core stuff from extras. I suspect that some places in the (auto)loading and/or compiling process have assumptions about everything being in .../lisp, but I have never checked. Cheers Ale
On 16 April 2011 11:09, Alessio Stalla <alessiostalla@gmail.com> wrote:
But since getting features like RUN-PROGRAM implemented quickly helps everyone out, maybe we should relax this somehow? Maybe placing such code in a different directory ("org/armedbear/lisp/jvm"?) Or use the CL package system to have a SYSTEM-JVM from which SYSTEM can inherit symbols? Does this architectural principle still make sense? Thanks for pointing it out. My opinion: it does make sense for the core ABCL (the CL package + the stuff in the SYSTEM package needed to implement CL). I'm not convinced it makes sense for all extensions which are not essential for the correct functioning of ABCL: the cost of having extra primitives written in Java and code to link the Java and Lisp pieces is relatively high for small extensions and the benefits are, imho, not worth that cost. That said, putting direct jnew, jcall etc. in the middle of Lisp code as I did is, as I now realize, bad style; it's better to have a little functional abstraction - (make-process-builder) rather than (jnew "java.lang.ProcessBuilder") - so that in case you want to port the same feature on a JVM with different standard libraries, you can isolate the conditionalization in a few functions rather than having ugly #+standard-jvm #+dalvik #+whatever spread all over the code.
It's better to have such an abstraction, indeed. RUN-PROGRAM is also an extension that we expect to support cross-platform/cross-vm, if we ever get to supporting multiple VMs. The situation is very different if we have an extension that's just for integrating to some external facility that only makes sense on a java VM, or a library that only exists on a java VM. At any rate, I'm all for having such an extension even if it initially uses jcall/jnew, we can do the abstractions as it evolves. I don't think we need to sit on our hands and not release such extensions just because it's not philosophically "correct" from the get-go. :)
On 4/16/11 4:04 PM, Ville Voutilainen wrote: […]
At any rate, I'm all for having such an extension even if it initially uses jcall/jnew, we can do the abstractions as it evolves. I don't think we need to sit on our hands and not release such extensions just because it's not philosophically "correct" from the get-go. :)
In practical terms, we rarely have the time to go back to correct things, so if we let this "slide", it will probably remain this way for a while. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 16 April 2011 17:19, Mark Evenson <evenson@panix.com> wrote:
At any rate, I'm all for having such an extension even if it initially uses jcall/jnew, we can do the abstractions as it evolves. I don't think we need to sit on our hands and not release such extensions just because it's not philosophically "correct" from the get-go. :) In practical terms, we rarely have the time to go back to correct things, so if we let this "slide", it will probably remain this way for a while.
Well, if that's a valid concern, I'd prefer this one being done through primitives rather than jcall. It fits the criteria of being non-java-specific.
participants (3)
-
Alessio Stalla -
Mark Evenson -
Ville Voutilainen