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

[Ville Voutilainen]

On 16 April 2011 11:09, Alessio Stalla <alessiostalla at 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. :)