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