I need to find a way for CL and Java programs to communicate closely.
Specifically, I'd like to put CL code into a Java EJB -- ideally,
there would be no need to access external files (like a Lisp
interpreter executable).
I've found a few possibilities:
* Franz's Allegro CL has a "Java Tool Suite" which claims to allow
calling Java from Lisp and vice-versa. I haven't really looked at
it yet.
* Something like kawa, which can compile Scheme into Java bytecode,
combined with either rewriting from CL to Scheme, or a hypothetical
CL implementation on top of Scheme. Maybe kind of ugly.
* A possibly ideal solution would be a CL to Java bytecode
compiler/interpreter. But I couldn't find any such beast in a web
search.
* Something else, that I just don't know about?
Have other people here had experience with this sort of thing? Any
recommendations?
Chris
--
----------------------------------------------------- ·····@mt.sri.com
Chris Jones SRI International, Inc.
Chris Jones <·····@mt.sri.com> writes:
> I need to find a way for CL and Java programs to communicate closely.
> * Something like kawa, which can compile Scheme into Java bytecode,
> combined with either rewriting from CL to Scheme, or a hypothetical
> CL implementation on top of Scheme. Maybe kind of ugly.
Current Kawa (in CVS) has some very embryonic Common Lisp support, and
has almost usable Emacs Lisp support. The Emacs Lisp support is
relevant, because ELisp has features that Scheme doesn't: Separate
function/value namesspaces, and conflated 'nil and '(). The Kawa
CommonLisp support is loosely the Emacs Lisp support, but using
lexical scoping. This compiles directly to bytecode, just the same as
the Scheme implementation - it does not go via Scheme. In my opinion
the way to go is to improve the Common Lisp support in Kawa. I am
interested in seeing this happen, and would be happy to help anyone
interested in working on it.
Of course full support for all of ANSI Common Lisp is a large project,
but if you can manage with a restricted subset (for example CLtL:1,
perhaps with some simplifications) it is much more doable. (I do have
an unimplemented design for CLOS-style multiple inheritance, based on
using interfaces, and Kawa also has some support for generic functions.)
Some recent discussion on the Kawa mailing list may be helpful.
Bradley Kuhn wants to compile Perl to JVM using Kawa, and he got
some useful feedback.
--
--Per Bothner
···@bothner.com http://www.bothner.com/~per/
In article <··············@kelso.bothner.com>,
Per Bothner <···@bothner.com> wrote:
[...]
> Of course full support for all of ANSI Common Lisp is a large project,
> but if you can manage with a restricted subset (for example CLtL:1,
> perhaps with some simplifications) it is much more doable. (I do have
> an unimplemented design for CLOS-style multiple inheritance, based on
> using interfaces, and Kawa also has some support for generic functions.)
[...]
I'm not offering to do it (i'm not good enough at Lisp), but at least some of
the stuff you'd have to implement is already available in Java (e.g.: hashes,
some of the stream stuff), so you should be able to create Lisp bindings to
this pre-existing Java stuff.
I think Kawa is great, would love to see it compile Common Lisp (or a
sufficiently large subset thereof).
glauber
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
Chris Jones <·····@mt.sri.com> writes:
> I need to find a way for CL and Java programs to communicate closely.
> Specifically, I'd like to put CL code into a Java EJB -- ideally,
> there would be no need to access external files (like a Lisp
> interpreter executable).
>
> I've found a few possibilities:
>
> [snip]
>
> * A possibly ideal solution would be a CL to Java bytecode
> compiler/interpreter. But I couldn't find any such beast in a web
> search.
Well, I happen to know someone who has this one as a 4th-year project
here at Cambridge, so while there doesn't currently exist one, there
might soon. I'll make him aware of the demand (I don't think he reads
this newsgroup).
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
In article <···············@merry.mt.sri.com>,
Chris Jones <·····@mt.sri.com> wrote:
> * A possibly ideal solution would be a CL to Java bytecode
> compiler/interpreter. But I couldn't find any such beast in a web
> search.
ACL 6 can do this...says so. Haven't tried it.
Re: EJBs -- folks have begun to pull their code out of Entity Beans due
to scaling problems and/or implementation problems and/or weaknesses
with the standard. There are no standard ways to map to legacy
data sources, for example.
Sent via Deja.com
http://www.deja.com/
········@my-deja.com writes:
> In article <···············@merry.mt.sri.com>,
> Chris Jones <·····@mt.sri.com> wrote:
>
>
> > * A possibly ideal solution would be a CL to Java bytecode
> > compiler/interpreter. But I couldn't find any such beast in a web
> > search.
>
> ACL 6 can do this...says so. Haven't tried it.
Ah, no. ACL 6 does not claim to be able to compile arbitrary CL code to
Java classes. It does have support for compiling an S-expression Java
syntax into Java classes -- which is pretty cool, but not at all the same
thing. :-)
And I wouldn't recommend ACL 6's approach as a solution to the original
poster's question. My suggestion would be Kawa.
[...]
-- Kaelin