On Wed, Feb 20, 2013 at 6:26 PM, Blake McBride blake@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@panix.com wrote:
On Feb 19, 2013, at 1420 , Blake McBride blake@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:
- Have you looked at JSS as Alessio suggests? Can you comment
as to how it meets your numbered points?
- 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@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel