[Jscheme-devel] SISC and Jscheme java interfaces...

[Timothy H. <tim...@ma...>]

Hi Scott,

I'm moving my response to the Jscheme list since I don't want
to clutter up your sisc-user mailing list with Jscheme discussion....

First, let me say that SISC is very nice and quite impressive.

> On Fri, May 31, 2002 at 09:29:25AM -0400, Timothy Hickey wrote:
>  > Hi,
>  >
>  >   I was playing with the SISC applet (very nice!)
>  > and realized that we could use Jscheme
>  >
>  >         http://jscheme.sourceforge.net
>  >
>  > to create a GUI interface for the SISC interpreter using
>  > Scheme instead of Java.
>
>  You can actually do this with SISC as well, though I believe your 
> point is
>  to use JScheme to compile scheme code into Java bytecode representing 
> the
>  GUI.
no. the point was just to show how the two Schemes could interface
very easily
>
>  >
>  > I haven't yet created a Jscheme applet for the SISC interpreter,
>  > but I've included below a simple Jscheme application.
>  >
>  > I thought it might be of interest to the SISC community to see how
>  > two different Java Schemes could work together. SISC seems to be
>  > written with R5RS conformance and high performance in mind,
>  > whereas Jscheme  was designed to allow easy access to Java.
>  >  It can be though of as a "Scheme skin" over Java....
>
>  You should check out the Java interface of SISC's in the manual, 
> you'll find
>  that though it doesn't have the 'dot notation' form that JScheme does, 
> it
>  is actually more powerful.
I'm interested in what features of the SISC interface to Java provide 
greater
power. The javadot notation seems to provide a very similar interface to
Java as the SISC approach as far as functionality goes. The Jscheme 
generic
functions also seem similar to SISC generics in that it provides a 
multi-method
like access to Java.
>
>  >
>  > Anyway, here is the little GUI application.
>  >
>  > You need to have both sisc.jar and jscheme.jar in your classpath
>  > and you issue the command
>  >
>  >   % java -cp jscheme.jar:sisc.jar jscheme.REPL SISCgui.scm
>  >
>  > Note:
>  > all Jscheme symbols that contain a "." or a "$" are
>  > interpreted as Java constructors, methods, fields, etc
>  > using the Javadot notation
>  >
>  > http://jscheme.sourceforge.net/jscheme/doc/javaprimitives.html
>
>  Ah, it appears you aren't using JScheme as a compiler.  You should
>  *definitely* read the SISC manual on this.  A very simple example
>  of creating a GUI with SISC can be found in CVS in the 
> sisc/tests/s2j.scm
>  file, where Matthias creates a dialog with three buttons just for 
> testing
>  purposes.
For comparison purposes I've included a comparison of the SISC and 
Jscheme
versions of that example.



  "this is the sisc code to make a window with three buttons:"
   (define <java.awt.Frame> (java-class "java.awt.Frame"))
   (define <java.awt.FlowLayout> (java-class "java.awt.FlowLayout"))
   (define <java.awt.Button> (java-class "java.awt.Button"))
   (define-generic set-layout)
   (define-generic add)
   (define-generic pack)
   (define-generic show)
   (define frame (make <java.awt.Frame>))
   (set-layout frame (make <java.awt.FlowLayout>))
   (for-each (lambda (s) (add frame (make <java.awt.Button> (->jstring 
s))))
             '(button1 button2 button3))
   (pack frame)
   (show frame)



"this is the jscheme code to do the same"
(define frame (java.awt.Frame.))
(.setLayout frame (java.awt.FlowLayout.))
(for-each
    (lambda(s) (.add frame (java.awt.Button. s)))
    '("button1" "button2" "button3"))
(.pack frame)
(.show frame)

The main difference seems to be that the first seven
lines of the SISC example are binding Java members to Scheme names and 
this
is done automatically in Jscheme (with some consequent loss of the 
namespace for
other purposes).

Also, SISC includes code to explicitly convert between Scheme and Java 
types
(->jstring s) and this is unnecessary in Jscheme as Jscheme uses the 
Java primitive
types directly. The disadvantage of the Jscheme approach is that it 
strings must then
by immutable which means we must deviate from R*RS.

We originally used an approach where one had to "declare" each 
class/constructor/method/field
before using it and it was not nearly as much fun to program with as the 
javadot notation.

I'm wondering if there might be some simple way to provide a javadot 
alternative
syntax for SISC. An easy way would be to have a global switch that, if 
enabled, would
allow SISC users to use javadot notation to access Java, e.g.
   java.awt.Frame.class  would have the same meaning as if one had defined
(define java.awt.Frame.class (java-class "java.awt.Frame"))
Likewise for java.awt.geom.Point2D$Float.class

and .add would have the same meaning as if there were global definitions
(define-generic .add (generic-java-procedure 'add))

In Jscheme we found we had to have an extended generic notation to work 
in an
applet context, e.g. we use
   .CLASSNAME.method
for instance methods where the object might be a private class 
implementing a public method!


   The key idea I'm proposing here is that it might be possible to
have a variant of SISC (specified with a command line switch
or a static variable or ...) which allowed javadot notation to be used
in SISC. There is the problem of converting between Scheme and
Java types, but it is worthwhile for we Jschemer to at least think
about it....

---Tim---



>
>  	Scott
>
>