From: <tho...@wi...> - 2007-10-12 09:10:40
|
Ville, You wrote: [lots of stuff deleted] > HTH, HAND > -VJV-=20 =20 Yes, that helps a lot. Thanks. Is there some specific documentation about this in a user manual or guide? What have I missed? I grabbed all the J user manual pages from the Web, but a grep -r didn't find much about `bytecode' or `byte'. |
From: Ville V. <vil...@gm...> - 2007-10-12 09:57:37
|
> >Yes, that helps a lot. Thanks. Is there some specific documentation > >about this in a user manual or guide? What have I missed? I grabbed I suppose this is just the way ABCL + JVM works in contrast to how the Java language runtime works with the JVM. The JVM is language-agnostic, at least in theory. The JVM and its bytecode are probably heavily Java-oriented as Java was for a very long time the only language that used the JVM bytecode as an intermediate representation. The constructs that Java uses are still just things build on top of the JVM bytecode - ABCL uses different constructs (built also on top of JVM bytecode), because it's not trivially straightforward to represent lisp types as java objects, or vice versa. Even though the underlying bytecode is the same (same as in adheres to the same bytecode standard, or an instruction set if you will), the type/object models of different languages built on top of the bytecode might be vastly different. The ABCL Interpreter provides the mapping from lisp types to Java objects. Of course it would probably be possible to include this mapping directly in the JVM bytecode generated by ABCL, but that would probably also be overkill for uses where the lisp-generated bytecode is only used by other ABCL byte code. There's also the problem that it's likely hard to find a Java-object-representation of lisp code that suits all purposes, I suppose utilizing the ABCL Interpreter as an intermediate mapper is a more generic approach and thus more flexible, even though it means that a simple use case of "let's invoke functions defined in lisp from java" is not as easy as using java functions from java. :) Same "impedance mismatch" can be seen when you invoke Java code from ABCL, or invoke Java code from C/C++ through JNI - Java is heavily object-oriented, it has no "free" functions (non-methods), so languages that *do* have "free" functions need to use a translation layer (in this case JNI) to invoke methods on java objects. The invocations are possible through the translation layer, but they are never as straightforward as invoking functions without a translation layer. The thing is, if there is no translation layer, the type/object models of the invoked code and the invoking code must match. To oversimplify, the matching object model is visible, sort of, by having an identical syntax on both sides (although syntax doesn't really mandate a type/object model). You can have a forced object model match (that would be having the ABCL generated byte code contain actual Java objects), but that would likely restrict the capability of the system to the lowest common denominator. As an example, if the ABCL byte code contained Java objects, how would you ever be able to invoke lisp macros? -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2007-10-12 10:22:18
|
On 10/12/07, Ville Voutilainen <vil...@gm...> wrote: > > > > >Yes, that helps a lot. Thanks. Is there some specific documentation > > >about this in a user manual or guide? What have I missed? I grabbed > > I suppose this is just the way ABCL + JVM works in contrast to how the Java > language > runtime works with the JVM. The JVM is language-agnostic, at least in > theory. The JVM > and its bytecode are probably heavily Java-oriented as Java was for a very > long time > the only language that used the JVM bytecode as an intermediate > representation. > The constructs that Java uses are still just things build on top of the JVM > bytecode - > ABCL uses different constructs (built also on top of JVM bytecode), because > it's not trivially straightforward to represent lisp types as java objects, > or vice versa. Even > though the underlying bytecode is the same (same as in adheres to the same > bytecode standard, or an instruction set if you will), the type/object > models of > different languages built on top of the bytecode might be vastly different. > > The ABCL Interpreter provides the mapping from lisp types to Java objects. > Of course > it would probably be possible to include this mapping directly in the JVM > bytecode generated > by ABCL, but that would probably also be overkill for uses where the > lisp-generated bytecode > is only used by other ABCL byte code. There's also the problem that it's > likely hard > to find a Java-object-representation of lisp code that suits all purposes, I > suppose > utilizing the ABCL Interpreter as an intermediate mapper is a more generic > approach > and thus more flexible, even though it means that a simple use case of > "let's invoke functions > defined in lisp from java" is not as easy as using java functions from java. > :) Well, if I understood the comments in src/org/armedbear/lisp/java.lisp correctly, then there's a macro there to generate java-like classes which can be accessed from java. Maybe that would help? bye, Erik. |
From: Ville V. <vil...@gm...> - 2007-10-12 12:20:27
|
> > >Well, if I understood the comments in src/org/armedbear/lisp/java.lisp > >correctly, then there's a macro there to generate java-like classes > >which can be accessed from java. Maybe that would help? > Well, the Interpreter object on the java side creates them anyway, so I don't really see any problem. Personally I don't (anymore :) wish to be able to load abcl code directly as java, because the Interpreter allows calling lisp functions and accessing lisp variables *without having to eval*. So if the problem is that you don't want to eval strings every time in order to invoke lisp code, you don't have to - the Interpreter has existing methods for this. ABCL in general lacks javadoc documentation, but the interface of Interpreter is not that hard to grasp, IMHO. -VJV- |