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. :)