[armedbear-devel] Seamless ABCL / Java integration proposal

[Alessio Stalla]

On Wed, Feb 20, 2013 at 6:26 PM, Blake McBride <blake at mcbride.name> wrote:
> I only looked briefly at JSS but quickly formed a, possibly unfounded,
> opinion as follows
>
> The appearance of the calls looks special and awkward.  In my case, nearly
> every line will be a call into my Java libraries.  This would render the
> lisp code maximumly awkward, ugly, and difficult to read.  The solution I
> had up to this point made the lisp code natural and native looking.
>
> I think the JSS code is nice if you have a few places you need to link into
> and didn't want to write the interface code.  Using ABCL as an extension
> language to a large application is an entirely different story.

In that case, I agree that using directly JSS or, worse, ABCL's native
FFI can become ugly. You should first write a wrapper Lisp API, maybe
not covering all methods, but just those that interest you.

> In terms of returning lists and arrays, I have many places where, for
> example, a method would return a list of records.  Using it as a lisp list
> when in lisp of very natural and works well with things like loop.  Having
> to call Java to iterate through lists and arrays is, again, unnecessarily
> unnatural.

You don't have to call into Java for that! You can, as I said, use
Java lists as native Lisp sequences (so, LOOP through them, MAP a
function over them, access them using ELT, etc.). Even if you don't
want to do that, you have better options, like converting them to Lisp
lists first, and then iterate through them using standard Lisp
functions, or writing your own generic collection traversal API.

> I think using that extension to clos I proposed could solve my problem but
> would be complicated to get working right.  I lean towards changing ABCL's
> REPL.  It would work as it does now but if it can't find a function, it
> automatically tries finding a Java method before issuing a function not
> found error message.  I think this would be pretty easy to implement and
> would automatically eliminate most interface code requirements, and render
> the interface natural to lisp.

It's not that easy. Leaving aside concerns about ANSI conformance, you
cannot get away with just modifying the REPL. What about compiled
code? Having code behave differently depending on whether it is EVALed
from the REPL or compiled would be very wrong, in my opinion.

In summary, ABCL can be very useful inside a Java application, but it
is not, and never will be if you ask me, a language for scripting
Java. The impedance mismatch between the two languages is just too
deep. Even Clojure, which is closer to Java, has its own dedicated
syntax for interop (not that different from JSS plus a few nice
operators for chained method calls), its own proprietary data
structures that are not 100% interchangeable with java.util
collections (due to immutability), its own arithmetic idiosyncrasies,
etc.

Cheers,
Alessio

>
> On Wed, Feb 20, 2013 at 5:08 AM, Mark Evenson <evenson at panix.com> wrote:
>>
>>
>> On Feb 19, 2013, at 1420 , Blake McBride <blake at mcbride.name> wrote:
>>
>> > Lest there be any confusion, I deeply appreciate the ABCL system and all
>> > those who contribute to it.
>>
>> From my side, I didn't intend my message to seem defensive, more
>> just a clarification of points that I have expressed to people, but
>> not on the mailing list.  And posts like yours are quite welcome.
>>
>> I'm still pondering how to answer your proposals, but it is taking a long
>> time to find the time.
>>
>> Just two quick points:
>>
>> 1.  Have you looked at JSS as Alessio suggests?  Can you comment
>> as to how it meets your numbered points?
>>
>> 2.  Changing the call/return values from the Java FFI in changing
>> java.lang.List to/from Lisp CONS as well as Java array to/from Lisp
>> arrays would break existing code that expects otherwise.  Any ideas
>> on how to migrate?
>>
>> --
>> "A screaming comes across the sky.  It has happened before but there is
>> nothing to compare to it now."
>>
>
>
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>



-- 
Some gratuitous spam:

http://ripple-project.org Ripple, social credit system
http://villages.cc Villages.cc, Ripple-powered community economy
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my current open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework