[Jscheme-user] Writing Java libraries in Scheme....

[Timothy J. H. <ti...@cs...>]

I think this recent change to JScheme (adding the jscheme.JScheme 
class),
finally allows us to create Java libraries in Scheme using a very simple
wrapping technique. Before this change there was always the possibility
that some other class could interfere with the classes JScheme 
environment
and hence the libraries would be particularly fragile. The ability to 
generate
multiple independent interpreters makes that problem go away.

I've started building some libraries this way (an example is below) and 
it
is actually quite nice. Assuming we package everything in a jar 
(including
the Scheme code) and that people download the jar and consult the 
javadoc
for instructions on how to use the package, only those who look closely
at the source will know that there is any Scheme involved at all...


On May 20, 2004, at 10:17 PM, Toby Allsopp wrote:
> On Thu, May 20, 2004 at 06:57:27PM -0400, Timothy John Hickey wrote:
>> On May 20, 2004, at 4:53 PM, Toby Allsopp wrote:
>>> I must say that after discovering Lisp it's painful to have to write
>>> Java.
>>
>> I agree, though I actually like the JVM and all of the Java libraries
>> and applications. With the new jscheme.JScheme class, I think we can
>> easily wrap Jscheme code in a Java class in such a way that no-one 
>> need
>> know it is written in Scheme. You just create a static JScheme
>> instance "js" as a private static variable, load in the code, and then
>> use js to provide functionality to all of the methods and initializers
>> of the class....
>
> Interesting idea, but wouldn't you have to have all your Scheme code in
> strings?  I suppose you could ship a .scm file along with the .class,
> but then it's a bit of a giveaway that you're using Scheme.
>

I actually don't mind if they know it was written using Scheme (in an 
open
source world thats in fact required).

I'm more interested in them being able to easily write Java classes with
all of the functionality given by Scheme code. This raises the issue of
what the scope of the JScheme instance should be. Should it be defined 
for
each instance of the class, or should there be one for  all instances 
of the
class.

Here's an example of a wrapping of some of the functionality of the
groupscheme/test/GroupServer.scm module from groupscheme.sourceforge.net
which works nicely....

> package groupdemo;
>
> public class GroupServerW {
>     // create a static JScheme instance for use by this class
>     // and initialize it to use the GroupServer module
>     static jscheme.JScheme js = null;
>     static {
>         js = new jscheme.JScheme();
>         js.eval("(use-module {groupscheme/test/GroupServer.scm})");
>     }
>
>     jscheme.SchemeProcedure groupserver=null;
>
>     public GroupServerW(int port) {
>         groupserver=
>           (jscheme.SchemeProcedure)
>             js.call("make-group-server",
>                      new Integer(port));    }
>
>     public void quit() {
>         js.call(groupserver,js.eval("'quit"));    }
>
>     public static void main(String[] args) {
>         js.call("main",args);    }
> }

This is the usual verbose Java boilerplate, but the nice thing is that 
all of the real
content is in the Scheme code accessed by js.call or js.eval 
expressions. Adding
the javadoc can be thought of as a way of commenting the Scheme code and
making it into a library for use by other Java or JScheme 
programmers....

and here is the code with some javadoc comments ....