On Mon, 24 Oct 2005 at 08:46:16 -0400, Rich Hickey wrote:
> N.B. I am not (yet) an ABCL user, but am very interested in its
> progress and especially in its Java interface. IMO, jLinker is not a
> good API to adopt if you ever want to support non-reflective, direct,
> compiled Java calls, and, as a language compiler, that is something
> ABCL should (eventually) support.
> jLinker definitely has a FFI feel, with an emphasis on 'foreign'. In
> addition, it was designed to run over a socket, where the overhead of
> doing so would dominate the reflection overhead.
> ABCL is in the unique position of being able to do something
> significantly more transparent/efficient. In developing jFli, Foil
> and most recently Clojure, I looked at both the jLinker and JavaDot
> APIs and found them both lacking in 2 key areas:
> Compilability - both require dynamic resolution of some constructs
> Editor Symbol Completion - neither support the generation of
> distinguished symbols so the user can leverage editor symbol
> completion e.g. to be prompted with the names of the members of a
> class, without yet another user-generated calling layer, and the
> attendant lack of portability of same. This is a very important feature.
> There are 2 other models already in use that do a better job in these
> areas. One is Kawa's, where the define-namespace construct (http://
> http://www.gnu.org/software/kawa/Method-operations.html) creates a pseudo
> module prepopulated with names corresponding to the Java fields and
> methods of the named class. The resulting symbols have distinct
> prefixes and other adornments and can support, with custom editor
> assistance (http://sourceforge.net/projects/schemeway/), editor
> completion. In addition, Kawa can then provide efficient static
> compilation in most cases, and supports type hinting to resolve
> overloading situations it wouldn't otherwise be able to figure out.
> The other model is the jFli/Foil/Clojure model where a preprocess is
> run on any Java packages that generates distinguished symbols for the
> types, methods, fields etc contained therein. In jFli/Foil these
> symbols are bound to invocation thunks, but in Clojure they are
> simply adorned with the metadata needed to support compilation. When
> the compiler encounters a symbol so adorned, it gets special
> treatment. In addition to supporting efficient compilation, this
> method has the advantage of using the normal symbol/package system,
> thus supporting completion with standard Lisp editors, and doesn't
> require a new language construct (modules/pseudo-packages), just some
> extended compiler semantics.
> Note that I am not negating the value and power of a dynamic
> interface, just saying that it's much easier to build a reflective
> interface on a compilable one than vice-versa.
First of all, I'm not sure the jlinker API is particularly unfriendly
If you have something like:
(jcall (jmethod "java.lang.String" "length") x)
the compiler can optimize away the call to JMETHOD entirely and will
replace the call to JCALL with a direct call to String.length(). (I'm
not saying ABCL's compiler does this today, but it should, and it
doesn't seem particularly hard to accomplish.)
Overloads muddy the waters a bit, but using type declarations in the
Lisp code, plus compile-time reflection and the compiler's normal type
derivation, should still make it possible to generate good code.
One thing I like about the jlinker funcall model, besides its general
DWIMishness, is that you're not forced to use CLOS.
But I agree that there is also room for the more ambitious approach,
where you do something like
and you get back a CLOS class that wraps the Java class, with all the
right slots and methods and transparent handling of overloads.
I basically like the way jFli handles this. Allegro also has a DEF-JAVA-
CLASS, but it has a considerably more verbose syntax and doesn't appear
to take advantage of compile-time reflection. I haven't looked at Foil
I'm not really sure whether this sort of thing is something that should
be part of ABCL, or whether it's better left to independent projects
The editor issue seems a bit odd to me, but I guess it goes away if
something like the jFli approach is supported.