[armedbear-devel] Seamless ABCL / Java integration proposal

[Alan Ruttenberg]

I thought of one more thing that had been bouncing around. Compiler
support for speed optimization. Currently I use the
with-constant-signature macro, which lets me express that within a
certain block a specified method will always be called with the same
signature. The implementation is to cache the method looked up by the
first call, and call that method throughout the rest of the block.
It's pretty helpful for bumming speed on tight looks, such as when
iterating through a large array or list. By doing this you save the
lookup against the cache (and it makes a difference in some code).

Ideally this would be expressed as a compiler directive like (declare
(constant-signature #"foo")) , which, if speed optimization was high
enough, would do as I say above. I suppose the same
declaration/optimization could be used for Clos method calls.

Finally, I haven't looked recently looked at the syntax for defining
java classes and methods in lisp. jinterface-implementation gets the
job done (though i used to have to be careful about exceptions - don't
know if I still need to). But one might think a syntax closer to clos
would be more familiar.

-Alan


On Sat, Feb 16, 2013 at 7:53 PM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> Hi Blake,
>
> I'm the original author of JSS and I completely agree. Have a look at JSS
> and see how it feels. Aside from the syntax, note that imports are not
> necessary, ABCL has incorporated dynamic additions to the classpath, one
> cnanan refer to classes using symbols or strings that only need to match
> uniquely to the end of the fully qualified class name and there are
> extensions to asdf that let you have jar files specified as part of system
> definitions.
>
> The only thing that has stumped me is how to dynamically add native
> libraries - it would be great if you or someone Else could figure out a way
> to let that happen. Also I think there's one remaining bug with method look
> up that we've reported that I don't think is addressed yet.
>
> I suspect it's the case that modifying a ABCL to use symbols as the function
> names is feasible just by modifying the readtable so you might give that a
> try. In the end I decided that because of the case sensitivity and the
> overlap with existing function names it was clearer to have a distinct
> syntax.
>
> Here's another item that I think would be a very nice addition towards the
> goal we both agree is worthwhile. I find myself regularly finding some code
> snippet or test program written in java that I want to use in abcl. Wouldn't
> it be sweet if there was a slime addition paste-as-jss that did the
> transforms necessary to translate from java syntax to jss in ABCL. This
> wouldn't have to be a full java parser - even support for a subset of
> statements and the ability to ignore much of the declaration nonsense that
> jss/abcl doesn't need, and the ability to leave alone what it doesn't know
> how to translate, would be a real help for lisp programmers who want to use
> java.
>
> Best,
> Alan
>
> On Saturday, February 16, 2013, Blake McBride wrote:
>>
>> 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
>>
>>
>