[armedbear-devel] Mixing Java/Lisp abstraction barrier in ABCL implementation

[Alessio Stalla]

On Sat, Apr 16, 2011 at 7:42 AM, Mark Evenson <evenson at panix.com> wrote:
> 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

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