CL+J is an exact, safe and complete Common Lisp interface to Java
through JNI.
In CL+J, Java methods are seen as normal Common Lisp functions with a
somewhat
different naming convention and Common Lisp functions can be exposed
to Java
as native methods. CL+J uses CFFI to accomplish this.
Version 0.1 is the first release of CL+J. It currently works under
SBCL or ECL either
on Linux/x86 or MS-Windows XP.
CL+J is released under an MIT-style license.
You can find more about CL+J at this address: http://common-lisp.net/project/cl-plus-j/
On Mar 20, 6:17 am, JCB <····················@gmail.com> wrote:
> CL+J is an exact, safe and complete Common Lisp interface to Java
> through JNI.
> In CL+J, Java methods are seen as normal Common Lisp functions with a
> somewhat
> different naming convention and Common Lisp functions can be exposed
> to Java
> as native methods. CL+J uses CFFI to accomplish this.
>
> Version 0.1 is the first release of CL+J. It currently works under
> SBCL or ECL either
> on Linux/x86 or MS-Windows XP.
>
> CL+J is released under an MIT-style license.
>
> You can find more about CL+J at this address: http://common-lisp.net/project/cl-plus-j/
Excellent. Just one question and one issue. How is it different from
Jfli? Are you aware that the #_ read macro is already used by non-SBCL
implementations for their own purposes?
Cheers
--
Marco
On 20 mar, 04:50, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 20, 6:17 am, JCB <····················@gmail.com> wrote:
>
> > CL+J is an exact, safe and complete Common Lisp interface to Java
> > through JNI.
> ...
> > You can find more about CL+J at this address: http://common-lisp.net/project/cl-plus-j/
>
> Excellent. Just one question and one issue. How is it different from
> Jfli?
To the risk of insisting on the obvious, please let me underline that
CL+J and jfli run on different lisp implementations, CL+J uses CFFI
which probably makes it largely portable to other lisps and jfli is
based on LispWorks' FLI which has kept it within the LispWorks family
until now. There is also a difference of philosophy between CL+J and
fli at the level of their public interface. CL+J does not create any
CL package shadowing the Java packages and tries to keep the syntax to
name Java entities as close to their original name as possible without
any form of translation. What you get in CL+J is exactly what Java
would have given you for the same denotation. Along the same idea, in
CL+J, there is no automatic translation of objects from CL to Java or
the reverse. The user needs to do explicit conversion (through "jtol"
or "ltoj") otherwise objects keep their original identity. There is
also a "pay as you go" philosophy in the use CL+J does of the Java
reflection data. In CL+J any attempt to give Java a more lisp flavor
is left to a layer to be put above it.
> Are you aware that the #_ read macro is already used by non-SBCL
> implementations for their own purposes?
>
I don't think there is an obvious mechanism to guaranty the
prevention of such unfortunate clashes in CL. There is nothing
fundamental in the choice of #_ and it could be easily changed. I am
obviously not aware of the #_ uses you are referring to. What
implementations are these?
Cheers,
Jean-Claude
On Mar 20, 10:25 am, JCB <····················@gmail.com> wrote:
> I don't think there is an obvious mechanism to guaranty the
> prevention of such unfortunate clashes in CL. There is nothing
> fundamental in the choice of #_ and it could be easily changed. I am
> obviously not aware of the #_ uses you are referring to. What
> implementations are these?
openmcl uses #_ extensively for foreign os calls
On 20 mar, 10:54, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 20, 10:25 am, JCB <····················@gmail.com> wrote:
>
> > I don't think there is an obvious mechanism to guaranty the
> > prevention of such unfortunate clashes in CL. There is nothing
> > fundamental in the choice of #_ and it could be easily changed. I am
> > obviously not aware of the #_ uses you are referring to. What
> > implementations are these?
>
> openmcl uses #_ extensively for foreign os calls
What about #> or #; as replacement?
I have a feeling that it may be impossible to please everyone all at
once...
On Mar 20, 11:21 am, JCB <····················@gmail.com> wrote:
> What about #> or #; as replacement?
>
> I have a feeling that it may be impossible to please everyone all at
> once...
#; doesn't appear to be used by openmcl.
#^ also appears to be available. I would prefer this as less likely to
be confused with a comment.
·@, #>, #_ are all in use by openmcl
On Mar 20, 4:44 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 20, 11:21 am, JCB <····················@gmail.com> wrote:
>
> > What about #> or #; as replacement?
>
> > I have a feeling that it may be impossible to please everyone all at
> > once...
>
> #; doesn't appear to be used by openmcl.
> #^ also appears to be available. I would prefer this as less likely to
> be confused with a comment.
>
> ·@, #>, #_ are all in use by openmcl
I think
#] could be a good choice. It is reminiscent of Java innards and it
is unlikely to be hijacked by people doing things with #[ or [. Also
#} may work. Note that no conforming implementation can use these
(http://www.lispworks.com/documentation/HyperSpec/Body/02_dh.htm).
Cheers
--
Marco
On 20 mar, 12:08, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 20, 4:44 pm, Raffael Cavallaro <················@gmail.com>
> wrote:
>
> > On Mar 20, 11:21 am, JCB <····················@gmail.com> wrote:
>
> > > What about #> or #; as replacement?
>
> > #; doesn't appear to be used by openmcl.
> > ·@, #>, #_ are all in use by openmcl
>
> #] could be a good choice.
> #} may work.
What would you say of replacing #_ with #j_ instead?
A bit longer but easy to read. No guaranty against a clash, I know...
Thanks for you help,
Jean-Claude
On Mar 20, 12:22 pm, JCB <····················@gmail.com> wrote:
> What would you say of replacing #_ with #j_ instead?
I was going to suggest this but I thought you wanted to keep it to one
character after the hash. I think either your #j_ or Marco's
suggestion of #] wold be most readable; j for java, or ] for ]ava.
JCB <····················@gmail.com> writes:
>> openmcl uses #_ extensively for foreign os calls
>
> What about #> or #; as replacement?
I suggest you use the named-readtables[1] library to avoid any such
clashes.
[1] darcs get http://common-lisp.net/~trittweiler/darcs/editor-hints
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
On 21 mar, 13:45, ·············@deadspam.com (Luís Oliveira) wrote:
>
> I suggest you use the named-readtables[1] library to avoid any such
> clashes.
>
Thank you very much Luis for this pointer. It looks like a quite
useful piece of code. But I think it will be more useful to a user of
CL+J than inside of it. All CL+J really has to do is to be flexible
enough to allow its effective use. I will change a bit the readtable
setup code to do just that.
Cheers,
Jean-Claude Beaudoin
JCB wrote:
> On 20 mar, 04:50, Marco Antoniotti <·······@gmail.com> wrote:
>> On Mar 20, 6:17 am, JCB <····················@gmail.com> wrote:
>>
>>> CL+J is an exact, safe and complete Common Lisp interface to Java
>>> through JNI.
>> ...
>>> You can find more about CL+J at this address: http://common-lisp.net/project/cl-plus-j/
>> Excellent. Just one question and one issue. How is it different from
>> Jfli?
>
> To the risk of insisting on the obvious, please let me underline that
> CL+J and jfli run on different lisp implementations, CL+J uses CFFI
> which probably makes it largely portable to other lisps and jfli is
> based on LispWorks' FLI which has kept it within the LispWorks family
> until now. There is also a difference of philosophy between CL+J and
> fli at the level of their public interface. CL+J does not create any
> CL package shadowing the Java packages and tries to keep the syntax to
> name Java entities as close to their original name as possible without
> any form of translation. What you get in CL+J is exactly what Java
> would have given you for the same denotation. Along the same idea, in
> CL+J, there is no automatic translation of objects from CL to Java or
> the reverse. The user needs to do explicit conversion (through "jtol"
> or "ltoj") otherwise objects keep their original identity. There is
> also a "pay as you go" philosophy in the use CL+J does of the Java
> reflection data. In CL+J any attempt to give Java a more lisp flavor
> is left to a layer to be put above it.
Sounds like some good design decisions in there.
kt
On Fri, 20 Mar 2009 12:48:41 -0400, Kenneth Tilton wrote:
> Sounds like some good design decisions in there.
OMG, Kenzo-san actually *praised* someone !
In other news: Hell is freezing over.
On Mar 20, 3:10 pm, alien_guy <····@l.org> wrote:
> On Fri, 20 Mar 2009 12:48:41 -0400, Kenneth Tilton wrote:
> > Sounds like some good design decisions in there.
>
> OMG, Kenzo-san actually *praised* someone !
>
> In other news: Hell is freezing over.
hey, he liked some of my song lyrics...
alien_guy wrote:
> On Fri, 20 Mar 2009 12:48:41 -0400, Kenneth Tilton wrote:
>> Sounds like some good design decisions in there.
>
> OMG, Kenzo-san actually *praised* someone !
Yeah, now you know how badly the rest of you suck.
hth, kenny