I wonder if there's a place in here for kawa (http://www.gnu.org/software/kawa/). It would be ideal for java-elisp communication, since it's a scheme environment that runs in Java. It even has an elisp mode!
Galen Boyer <[EMAIL PROTECTED]> writes: > On Tue, 18 Feb 2003, [EMAIL PROTECTED] wrote: >> Sounds like a great idea! >> >> I would volunteer to re-write the Jalopy >> (http://jalopy.sourceforge.net/) integration package I put >> together. I could also take a stab at a re-write for the >> integration package for PMD (http://pmd.sourceforge.net/). >> >> Those Elisp->Java packages have an awful lot of code in common, >> and it would be really nice to create a standard way to create >> them - specially the bit about a standard way to integrate with >> the BeanShell. >> >> I would like to suggest also a standard way for those packages >> to present their output. A lot of them generate warnings or >> errors that go very well in a "compilation" mode buffer. I >> think this behavior can be abstracted as well. > > > Maybe the beanshell could be viewed as an application server. > > Let me work through my thoughts. > > Would it make sense that java code that is executed through the > beanshell not have to "println(someElispString);" but instead, > any java code that is to be executed by the beanshell and > subsequently eval'd into elisp, return a "java datatypes > transformable to elisp" set of objects, like hashmap, array, ... > > Then, the beanshell could offer a set of classes which take these > particular return objects and transform them into println's of > elisp strings to be eval'd by elisp. The only part that doesn't > seem clear to me is how to have elisp not have to understand the > java code, its structure and exact names as well as its exact > syntax. I'm thinking, first an eieio interface to elisp be > required to be implemented by the elisp code of the package. A > mapping layer, maybe xml, or just elisp list, be used to wire > elisp class/method names to java class/methods. Then, the elisp > package integrates with a particular elisp interface and the java > code integrates with a particular java interface and the elisp to > java is the black box that none of the two sides of code knows > about, taken care of by the beanshell's black box. > > This would also allow java requirements for some particular need > of the JDEE to be given to a willing java coder and the elisp > requirements given to a willing elisp coder and the two sides > actually code in their respective VMs without having to hook the > two, fairly incompatible VMs up during development. Of course, > what I'm thinking is that a JDE user could integrate some jakarta > package by working with Paul on the java interface needing to be > implemented. Paul or another of the elisp studs, then codes up > the elisp side of the house waiting for the java coder to finish > his work. > > Then, elisp becomes a client and the java code becomes the > middleware implementing interfaces the beanshell application > server will be executing. > > -- > Galen Boyer
