[armedbear-devel] Seamless ABCL / Java integration proposal

[Blake McBride]

I'd like to add that there are many high quality and free lisp systems
available.  The thing that makes ABCL uniquely interesting is its close
association to Java.  It gives ABCL a much better ability to leverage off
of the existing technology (libraries) built in Java.  While focusing on
ABCL's reliability and conformance to standards is very important, I
wouldn't loose sight of where the attraction really is.  If the main
attraction to ABCL for lisp programmers is its tight integration to Java,
than the degree of ABCL's appeal will be directly related to the ease and
power of its integration to Java.

Just one opinion...

Blake McBride



On Sat, Feb 16, 2013 at 7:54 AM, Alessio Stalla <alessiostalla at gmail.com>wrote:

> On Sat, Feb 16, 2013 at 2:32 PM, Blake McBride <blake at arahant.com> wrote:
> > I have an idea for a largely seamless integration method for ABCL with
> Java
> > that involves changing the ABCL REPL.  It would work as follows.
> >
> > 1.  From within Java or lisp, have the ability to register any number of
> > Java classes with ABCL.
> >
> > 2.  When executing lisp code of the form (fun args ...), try running the
> > code as regular lisp code as it does now, but if it fails to find the
> lisp
> > function and has at least one argument then:
> >
> > 3.  Examine the arguments and, through reflection, try to find a Java
> method
> > (with the same name as the lisp function) in one of the registered Java
> > classes that matches the number and types of arguments and execute that.
> > So, it would auto translate (in effect):
> >
> >     (fun arg1 arg2 arg3 ...)
> >
> > into Java
> >
> >     arg1.fun(arg2, arg3, ...);
> >
> > 4.  There must be better auto-translation of lisp <-> java data types to
> > include arrays and lists in order for this to work.  So, in other words,
> > when executing a lisp function passing a lisp array as one of the
> arguments,
> > the Java reflection query will see a Java array argument type.  It will
> also
> > be auto-converted when making the call.
> >
> > 5.  There must be some sort of cacheing mechanism to avoid redundant Java
> > reflection calls.
> >
> > 6.  This mechanism must take into account and correctly handle similar
> Java
> > method names with different number and types of arguments both within and
> > across different classes.  It must also handle the fact that methods may
> be
> > declared in Java superclasses.
> >
> > 7.  This functionality can be enabled or disabled through some (Java
> and/or
> > lisp function).  Off by default to avoid troubles.
> >
> > Adding this functionality would make ABCL a plugin-and-go extension to
> Java.
> > Any code could be written in Java or lisp immediately without complicated
> > and cumbersome interface/translation code in most cases.  There would be
> no
> > huge initial hill to climb (to create all the interface code), and the
> usage
> > would be natural and uncomplicated.
> >
> > Thanks.
>
> I never really used it, but it seems to me that you're mostly
> describing JSS. It is not so seamlessly integrated with the REPL, but
> it has reader macros that allow you to write (#"someMethod" this arg1
> arg2 ...). ABCL (and thus JSS) knows how to find the best matching
> method based on argument types, taking subclassing into account.
>
> Lisp lists are not automatically translated to Java lists because they
> are made of conses, but a cons does not necessarily translate to a
> list, it might represent an improper list, a tree, a graph... on the
> other hand, you can use Java lists natively as Lisp sequences in ABCL,
> so you might be better off using Java lists from the start, if you
> find yourself converting lists back and forth frequently.
>
> Alessio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130216/963cb744/attachment.html>