jscheme-devel — Developer's list

[Jscheme-devel] CVS-update

[Ken A. <kan...@us...>]

Update of /cvsroot/jscheme/jscheme/src/dclass
In directory usw-pr-cvs1:/tmp/cvs-serv25094/src/dclass

Modified Files:
	SAXHandler.scm dclass.scm 
Log Message:
Have dclass compile into the src directory by default.
Have the Sax* classes compile into elf package.

Re: [Jscheme-devel] SISC's Scheme-to-Java interface

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

On Monday, June 3, 2002, at 04:03 AM, Matthias Radestock wrote:

> Timothy Hickey wrote:
>
>> Jscheme does have a form of multi-methods similar to SISC's 
>> define-method, but rather than
>> using chaining it lets you bind multiple functions to the same name 
>> and then selects the best match
>> using dynamic dispatch,
>
> Perhaps you misunderstood me. Generic procedures in SISC have methods 
> that get selected based on the argument types - just like in JScheme 
> (and CLOS, Dylan etc etc). Chaining is an additional concept that 
> allows one generic procedure to delegate calls to another generic 
> procedure when it cannot find a suitable match. By default
>  (define-generic foo)
> will create a "normal" generic procedure to which any methods are added 
> with (define-methd (foo ...) ...), and chain it to a *special* generic 
> procedure containing all Java methods "foo" of all classes.
Now I understand. Thanks.

>
>>> * The names of generic procedures by default are mapped to Java 
>>> method names via an "unschemification" conversion, e.g. foo-bar-baz? 
>>> becomes isFooBarBaz. This further blurs the distinction between doing 
>>> "schemy" things and "javay" things.
>> This is cute! But its not essential, is it? Couldn't you just as well 
>> have used straight Java syntax here...
>
> Yes. The philosophy behind the S2J interface in SISC is very much one 
> of making Java blend in with Scheme. Another reason is that SISC, by 
> default, is case-insensitive which would make using straight Java names 
> awkward. You can do so by doing something like
>   (define-generic |isFooBar| (generic-java-procedure '|isFooBar|)
> Note the || notation for case-sensitive symbols. Btw, this example also 
> makes the chaining explicit - the generic-java-procedure call retrieves 
> the generic procedure containing all methods isFooBar of all classes.
Ahh yes. I had forgotten about case insensitivity.

>
>>> * constructors are generic procedures too.
>> ??????????
>> Do you use chaining for selecting the appropriate constructor or 
>> method for a straight Java call?
>> e.g. if there are five different constructors, does SISC select the 
>> one that best matches the arguments
>> or the one that "first" matches the arguments (with respect to some 
>> ordering...)
>> ??????????
>
> Here's an example:
> (define-constructor (<jstring> (next: next-method)
>                                (<jchar> c))
>   (next-method (->jarray (list c) <jchar>)))
> (make <jstring>) ;calls Java method
> (make <jstring> (->jchar #\o)) ;calls scheme method
>
> Handling constructors is actually somewhat complex. 'make' maintains a 
> table of generic procedures - one per class. The above example adds a 
> method to one of these, i.e. the generic procedure representing the 
> <jstring> constructors. The generic procedures are chained to generic 
> procedures holding all the Java constructors, again, on a per-class 
> basis. Constructor selection is based on looking up the generic 
> procedure for the constructors of the given class and then doing a 
> normal best-match selection on the methods.
I understand.

>
>>> Note that at the moment SISC generic procedures can only operate on 
>>> Java objects, not Scheme objects (unless, of course, you use their 
>>> Java representation). That will change soon though with the 
>>> introduction of a SISC type system and object system.
>> I look forward to seeing this, but it may be confusing having two type 
>> systems (Java and SISC) to consider. I think
>> Jython has some experience dealing with these issues.
>
> The Java type system frankly isn't good enough for me :)
> The two type systems will be integrated, i.e. it's going to be just one 
> type system of which the Java types are a part of.
Hmmm. Could you make the Java part optional or switchable. There has 
been some interest from Microsoft in
building .NET schemes.  They might be interested in a SISC#.  It seems 
that you are well on the way to defining
a generic interface to OO languages that support reflection (e.g. 
SISC-java, SISC-C#, SISC-goo?, ...)

>
>>> 4) Many JScheme types map directly to standard Java types, making 
>>> type conversion unnecessary when objects cross the Scheme/Java 
>>> divide. In SISC explicit conversion is needed.
>> Indeed, Jscheme is probably best thought of as a Scheme-skin for Java. 
>> It really is programming in Java,
>> but the syntax is different and some higher order procedure patterns 
>> have been incorporated into the syntax.
>> We're currentlly working on a syntax for implementing Java classes 
>> using Jscheme, which would complete this
>> analogy.
>
> I see. I don't think SISC is going to go down the route of class 
> generation. There are obvious limitations to using only reflection, but 
> it fits in better with the SISC philosophy.

>
>>> * For some Scheme types, such as numbers, the mapping to Java types 
>>> is one-to-many, e.g. a Scheme number could be converted to a byte, 
>>> short, int, etc. This causes ambiguities when automatic conversion of 
>>> parameters is attempted.
>> Makes sense (but couldn't a best fit mapping be made by default, i.e. 
>> choose the smallest applicable type ....)
>
> Yes, but when using generic procedures things start to get messy. See 
> the point further down my original list.
>
>>> * Some Java types have several corresponding Scheme types, e.g. a 
>>> Java array could be represented as Scheme list or vector - this 
>>> causes ambiguities when automatic conversion of results is attempted.
>>  The main problem is conversion from Scheme to Java (for procedure 
>> calls), i.e., what do Strings, Lists,
>> and Vectors maps to.  Converting back to Scheme could just do the 
>> reverse.
>
> The problem is that you start making arbitrary choices and thus taking 
> away choice from the user.
> Whether I want an array returned "as is", as a list, or as a vector 
> depends on the context. Sure, if the call always returns a vector I can 
> convert things back into an array, or into a list, but a) I end up 
> doing two conversions instead of one, b) in the array->vector->array 
> conversion the object identity of the array is lost.
This discussion is reminiscent of the AWT/Swing/SWT debate on the use of 
peers in building window systems.
AWT uses peers exclusively (as in Jschemes use of Java types), Swing 
eschews the use of almost all peers (as in SISCs
use of its own internal types), and SWT from IBM uses a mixture of both.

>
>> Conversion is indeed a tricky problem. It seems mandated by the need 
>> to have mutable Strings
>
> No. That's just one reason. All the other reasons I mentioned are much 
> more important.
>
>> Then you could just use a straight embedding of all
>> other Scheme objects into Java
>> by adding the Pair, Procedure, and Continuation classes to the public 
>> Java API for SISC....
>> Do you think this might work???
>
> These classes already exist and you can pass unconverted instances to 
> Java by wrapping them, e.g.
>  (println (<jsystem> 'err) (java-wrap '(1 2 3)))
>
> I could have made the wrapping implicit, but at the moment it isn't. I 
> might still change my mind on that.
>
> Generally, I want to keep the Scheme types distinct from the Java 
> types. That's a different approach to JScheme, but is more suitable for 
> SISC.
I see (and it seems like it might be portable to other Schemes, 
including those not written in Java, using the JNI....)

>
>> Anyway, I want to thank you for taking the time to write this 
>> explanation.
>
> You are welcome. I've learned a lot more about JScheme in the process.
 From my perspective SISC and Jscheme are not direct competitors anymore 
than Java and Scheme are.
I really do view Jscheme as Java programming using a Scheme-like syntax 
and semantics, where SISC
seems to be a high quality Scheme which happens to be implemented in 
Java.

>
>> It helps clarify the similarities and differences. I want to look at 
>> the
>> way we handle define-method, perhaps we should allow it to be
>> used over javadot names and to let it use the " . rest)" notation
>> as SISC's  define-method does...
>
> I'd encourage you to read the SISC manual and the code. The generic 
> procedure code is actually reasonably portable.
I have downloaded it and started to read it, but I actually have had 
some trouble getting the java-interface to work
(e.g. java-class seems to be undefined). I'm sure I'm just forgetting to 
load the right module or something equally silly,
but I haven't had a lot of time to work on it yet.

>
>> I'm still interested in the possibility of adding javadot notation to 
>> SISC.
>
> It's possible. You are only saving one line of code per method name 
> though at the expense of having to use the uglier (IMHO ;) Java names.
But thats one line for each "use" of a javadot symbol and when 
programming a big Java application with lots of library
use each line of Jscheme can contain many many javadot symbols, e.g. the 
six lines of code after the imports
contain 10 javadot symbols and this is pretty typical. (It is taken from 
an early email in this thread...)

(import "java.util.zip.*")
(import "java.io.*")
(import "sisc.*")
(import "sisc.data.*")

;; initialize SISC
(define in (GZIPInputStream. (BufferedInputStream. (FileInputStream. 
(File. "sisc.heap")))))
(define ctx (AppContext.))
(Context.register "main" ctx)
(define r (Context.enter "main"))
(REPL.initializeInterpreter r (list->array String.class '()) in)
(Context.exit)

;; The code above is an approximate Jscheme translation of the following 
java code from
;;  sisc.contrib.applet.SISCApplet.java (but the sisc.heap is read from 
a File not a URL...)

import sisc.*;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.net.*;
import java.util.zip.*;
  ....snip.....
             URL u=new URL(getDocumentBase(),"sisc.heap");
             URLConnection conn=u.openConnection();
             AppContext ctx = new AppContext();
             Context.register("main", ctx);
             Interpreter r = Context.enter("main");
             InputStream in=new GZIPInputStream(new 
BufferedInputStream(conn.getInputStream()));
             REPL.initializeInterpreter(r, new String[0], in);
             Context.exit();
....snip....

On the otherhand, the SISC style probably encourages developers to 
develop Scheme libraries providing
access to Java and hence make the resulting code more schemish.

>
>> I think Geoff's suggestions was to look into a way of finding a 
>> canonical
>> method for converting SISC values into Scheme values (e.g. numbers
>> go to ints if possible, the longs if possible, then doubles, the 
>> floats, then
>> BigIntegers or BigDecimals, but inexacts always goto doubles, floats, 
>> and
>> BigDecimals.
>
> The problem with conversion based on range is that if a Java method is 
> overloaded on, say, byte, int and long then you have no idea which one 
> is going to get called.
Yes this does create a problem...
>  In many cases this won't matter, because the methods will usually all 
> do the same thing, but not always.




>
> Also, note that the numeric types are not sub-types of each other, e.g. 
> int is not a sub-type of long. Since selection of methods from a 
> generic procedure is based on types, automatic conversion to the 
> smallest type will result in failures to find appropriate methods. Java 
> gets around this by performing a widening conversion, which is 
> completely orthogonal to type-conversion (i.e. the implicit casting to 
> a base class) and not a concept I would want to introduce into SISC's 
> type system.
Yes, we played with widening for a while, but have since removed it.

>
>> Thus, SISC could support a version of javadot with automatic 
>> conversion.
>> It might even be possible to have javadot and the current SISC/java 
>> interface work concurrently...
>
> Yes. Anyone who wants to implement automatic conversion between Scheme 
> and Java types in SISC this is welcome to do so. I can certainly see 
> the attraction of the idea and perhaps some applications would indeed 
> benefit from it. However, in the general case I believe that it creates 
> more problems than it solves, which is why I decided against this 
> strategy.
I think you made the right choice for SISC as the resulting system is 
truly a R5RS Scheme interface to Java and could
easily be replaced with a similar interface to C# or other OO 
languages...

My experience with Jscheme is leading me to believe that there is 
considerable latent power in
principled, multilingual programming. Jscheme and SISC present two 
different approaches to this
programming scheme.

Cheers,
---Tim---



>
>
> Matthias.
>

Re: [Jscheme-devel] SISC's Scheme-to-Java interface

[Matthias R. <mat...@so...>]

Timothy Hickey wrote:

> Jscheme does have a form of multi-methods similar to SISC's 
> define-method, but rather than
> using chaining it lets you bind multiple functions to the same name and 
> then selects the best match
> using dynamic dispatch,

Perhaps you misunderstood me. Generic procedures in SISC have methods 
that get selected based on the argument types - just like in JScheme 
(and CLOS, Dylan etc etc). Chaining is an additional concept that allows 
one generic procedure to delegate calls to another generic procedure 
when it cannot find a suitable match. By default
  (define-generic foo)
will create a "normal" generic procedure to which any methods are added 
with (define-methd (foo ...) ...), and chain it to a *special* generic 
procedure containing all Java methods "foo" of all classes.

>> * The names of generic procedures by default are mapped to Java method 
>> names via an "unschemification" conversion, e.g. foo-bar-baz? becomes 
>> isFooBarBaz. This further blurs the distinction between doing "schemy" 
>> things and "javay" things.
> 
> This is cute! But its not essential, is it? Couldn't you just as well 
> have used straight Java syntax here...
> 

Yes. The philosophy behind the S2J interface in SISC is very much one of 
making Java blend in with Scheme. Another reason is that SISC, by 
default, is case-insensitive which would make using straight Java names 
awkward. You can do so by doing something like
   (define-generic |isFooBar| (generic-java-procedure '|isFooBar|)
Note the || notation for case-sensitive symbols. Btw, this example also 
makes the chaining explicit - the generic-java-procedure call retrieves 
the generic procedure containing all methods isFooBar of all classes.

>> * constructors are generic procedures too.
> 
> ??????????
> Do you use chaining for selecting the appropriate constructor or method 
> for a straight Java call?
> e.g. if there are five different constructors, does SISC select the one 
> that best matches the arguments
> or the one that "first" matches the arguments (with respect to some 
> ordering...)
> ??????????
> 

Here's an example:
(define-constructor (<jstring> (next: next-method)
                                (<jchar> c))
   (next-method (->jarray (list c) <jchar>)))
(make <jstring>) ;calls Java method
(make <jstring> (->jchar #\o)) ;calls scheme method

Handling constructors is actually somewhat complex. 'make' maintains a 
table of generic procedures - one per class. The above example adds a 
method to one of these, i.e. the generic procedure representing the 
<jstring> constructors. The generic procedures are chained to generic 
procedures holding all the Java constructors, again, on a per-class 
basis. Constructor selection is based on looking up the generic 
procedure for the constructors of the given class and then doing a 
normal best-match selection on the methods.

>> Note that at the moment SISC generic procedures can only operate on 
>> Java objects, not Scheme objects (unless, of course, you use their 
>> Java representation). That will change soon though with the 
>> introduction of a SISC type system and object system.
> 
> I look forward to seeing this, but it may be confusing having two type 
> systems (Java and SISC) to consider. I think
> Jython has some experience dealing with these issues.
> 

The Java type system frankly isn't good enough for me :)
The two type systems will be integrated, i.e. it's going to be just one 
type system of which the Java types are a part of.

>> 4) Many JScheme types map directly to standard Java types, making type 
>> conversion unnecessary when objects cross the Scheme/Java divide. In 
>> SISC explicit conversion is needed.
> 
> Indeed, Jscheme is probably best thought of as a Scheme-skin for Java. 
> It really is programming in Java,
> but the syntax is different and some higher order procedure patterns 
> have been incorporated into the syntax.
> We're currentlly working on a syntax for implementing Java classes using 
> Jscheme, which would complete this
> analogy.
> 

I see. I don't think SISC is going to go down the route of class 
generation. There are obvious limitations to using only reflection, but 
it fits in better with the SISC philosophy.

>> * For some Scheme types, such as numbers, the mapping to Java types is 
>> one-to-many, e.g. a Scheme number could be converted to a byte, short, 
>> int, etc. This causes ambiguities when automatic conversion of 
>> parameters is attempted.
> 
> Makes sense (but couldn't a best fit mapping be made by default, i.e. 
> choose the smallest applicable type ....)

Yes, but when using generic procedures things start to get messy. See 
the point further down my original list.

>> * Some Java types have several corresponding Scheme types, e.g. a Java 
>> array could be represented as Scheme list or vector - this causes 
>> ambiguities when automatic conversion of results is attempted.
> 
>  The main problem is conversion from Scheme to Java (for procedure 
> calls), i.e., what do Strings, Lists,
> and Vectors maps to.  Converting back to Scheme could just do the reverse.

The problem is that you start making arbitrary choices and thus taking 
away choice from the user. Whether I want an array returned "as is", as 
a list, or as a vector depends on the context. Sure, if the call always 
returns a vector I can convert things back into an array, or into a 
list, but a) I end up doing two conversions instead of one, b) in the 
array->vector->array conversion the object identity of the array is lost.

> Conversion is indeed a tricky problem. It seems mandated by the need to 
> have mutable Strings

No. That's just one reason. All the other reasons I mentioned are much 
more important.

> Then you could just use a straight embedding of all
> other Scheme objects into Java
> by adding the Pair, Procedure, and Continuation classes to the public 
> Java API for SISC....
> Do you think this might work???

These classes already exist and you can pass unconverted instances to 
Java by wrapping them, e.g.
  (println (<jsystem> 'err) (java-wrap '(1 2 3)))

I could have made the wrapping implicit, but at the moment it isn't. I 
might still change my mind on that.

Generally, I want to keep the Scheme types distinct from the Java types. 
That's a different approach to JScheme, but is more suitable for SISC.

> Anyway, I want to thank you for taking the time to write this explanation.

You are welcome. I've learned a lot more about JScheme in the process.

> It helps clarify the similarities and differences. I want to look at the
> way we handle define-method, perhaps we should allow it to be
> used over javadot names and to let it use the " . rest)" notation
> as SISC's  define-method does...
> 

I'd encourage you to read the SISC manual and the code. The generic 
procedure code is actually reasonably portable.

> I'm still interested in the possibility of adding javadot notation to SISC.

It's possible. You are only saving one line of code per method name 
though at the expense of having to use the uglier (IMHO ;) Java names.

> I think Geoff's suggestions was to look into a way of finding a canonical
> method for converting SISC values into Scheme values (e.g. numbers
> go to ints if possible, the longs if possible, then doubles, the floats, 
> then
> BigIntegers or BigDecimals, but inexacts always goto doubles, floats, and
> BigDecimals.

The problem with conversion based on range is that if a Java method is 
overloaded on, say, byte, int and long then you have no idea which one 
is going to get called. In many cases this won't matter, because the 
methods will usually all do the same thing, but not always.

Also, note that the numeric types are not sub-types of each other, e.g. 
int is not a sub-type of long. Since selection of methods from a generic 
procedure is based on types, automatic conversion to the smallest type 
will result in failures to find appropriate methods. Java gets around 
this by performing a widening conversion, which is completely orthogonal 
to type-conversion (i.e. the implicit casting to a base class) and not a 
concept I would want to introduce into SISC's type system.

> Thus, SISC could support a version of javadot with automatic conversion.
> It might even be possible to have javadot and the current SISC/java 
> interface work concurrently...
> 

Yes. Anyone who wants to implement automatic conversion between Scheme 
and Java types in SISC this is welcome to do so. I can certainly see the 
attraction of the idea and perhaps some applications would indeed 
benefit from it. However, in the general case I believe that it creates 
more problems than it solves, which is why I decided against this strategy.


Matthias.

Re: [Jscheme-devel] SISC's Scheme-to-Java interface

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

Hi Matthias,

   Thanks for giving us your insights on the SISC java interface 
implementation...

On Sunday, June 2, 2002, at 06:16 AM, Matthias Radestock wrote:

> Hi JSchemers,
>
> I've been following the recent "SISC and JScheme java interfaces" 
> thread. As the author of SISC's Scheme-to-Java interface I figured it 
> might be a good idea to explain some of its features and the design 
> rationale behind them.
>
> The main differences between the SISC and JScheme approach are the 
> following:
>
> 1) JScheme uses special syntax to invoke Java methods. SISC uses a set 
> of primitives, procedures and macros to represent Java methods as 
> generic procedures.
>
> The special syntax approach makes JScheme code very compact and 
> readable, at the expense of chewing up a portion of the name space.
The name space is chewed up, but not fully digested!
In fact,  Jscheme just provides initial bindings to the javadot symbols, 
but you can easily redefine them.
e.g.,

   > (define Date. (let ((d Date.)) (lambda() (string-append "the date 
is " (d)))))
   > (Date.)
   "the date is Sun Jun 02 23:25:02 EDT 2002"

   > (define (f Date.) (* Date. Date.))
   {jsint.Closure f[1] (Date.)}
   > (f 4)
   16

Thus, javadot can be though of as a loading a large module of primitives
(although the bindings are not made until the first time the symbol 
value is looked up)

>  In SISC every Java method has to declared using
>  (define-generic foo ...)
>
> One pervasive concept throughout SISC's generic procedure mechanism is 
> that of chaining - the chainee procedure gets invoked when the chainer 
> procedure cannot find a matching method on invocation.
> The most common place where this is used is in order to add 
> Scheme-level methods "in front" of Java methods, basically performing a 
> kind of overloading. This means you can do things like this:
>
> (define-generic app (generic-java-procedure 'append))
> (define-method (app (next: next-method)
>                     (<jstringbuffer> buf) . rest)
>   (for-each (lambda (x) (next-method buf x)) rest)
>   buf)
> (define sb (make <jstringbuffer> (->jstring "foo")))
> (app sb (->jstring "foo") (->jint 1) (->jstring "bar"))
> ;==> stringbuffer now contains "foofoo1bar".
>
> Note that because SISC uses no special notation for calling Java 
> methods, the same name as before can be used to call the new procedure.
Very nice! The chaining idea is an interesting way to add functionality 
to java classes
or to other scheme procedures. Its seems to be similar to inheritance, 
except that the parent procedures
have priority rather than the other way round.


Jscheme does have a form of multi-methods similar to SISC's 
define-method, but rather than
using chaining it lets you bind multiple functions to the same name and 
then selects the best match
using dynamic dispatch,
e.g., the following code (take from jscheme/src/elf/iterate.scm) defines
an iterate method
   (iterate CompoundObject Action)
which is a "for-each" for all sorts of compound objects:

(import "java.lang.Object")
(import "java.lang.String")

(define-method (iterate (mapper jsint.Procedure) action)
   (mapper action))

;;; Hashtable and Vector specialization are only needed for JDK 1.1
(define-method (iterate (items java.util.Hashtable) action)
   (iterate (.elements items) action))

(define-method (iterate (items java.util.Vector) action)
   (iterate (.elements items) action))

(define-method (iterate (items java.util.Enumeration) action)
   (let loop ()
     (if (.hasMoreElements items)
         (begin (action (.nextElement items))
              (loop)))))
(define-method (iterate (items jsint.Pair) action)
   (let loop ((items items))
     (if (pair? items)
         (begin
           (action (car items))
           (loop (cdr items))))))

(define-method (iterate (items Object[]) action)
   (let loop ((i 0)
              (L (vector-length items)))
     (if (< i L) (begin (action (vector-ref items i)) (loop (+ i 1) L)))))

(define-method (iterate (items String) action)
   (let loop ((i 0)
              (L (string-length items)))
     (if (< i L) (begin (action (string-ref items i)) (loop (+ i 1) L)))))

....etc... (see jscheme/src/elf/iterate.scm for more)


>
> Here's a list of some other interesting features of SISC generic 
> procedures:
>
> * they are lexically scoped; One can define the same generic procedure 
> name in multiple scopes/modules withouth them inteferring with each 
> other.
Nice. Jscheme generic functions as defined using "define-method" are 
globally scoped.
The javadot symbols are also defined in the outermost scope.

>
> * the first parameter is not special. It participates in method 
> selection just like any other parameter.
Jscheme's define-method also does not give any special significance to 
the first parameter.
Jscheme's javadot does give special signficance to the first parameter 
for instance methods and instance fields.

>
> * The names of generic procedures by default are mapped to Java method 
> names via an "unschemification" conversion, e.g. foo-bar-baz? becomes 
> isFooBarBaz. This further blurs the distinction between doing "schemy" 
> things and "javay" things.
This is cute! But its not essential, is it? Couldn't you just as well 
have used straight Java syntax here...

>
> * constructors are generic procedures too.
??????????
Do you use chaining for selecting the appropriate constructor or method 
for a straight Java call?
e.g. if there are five different constructors, does SISC select the one 
that best matches the arguments
or the one that "first" matches the arguments (with respect to some 
ordering...)
??????????

>
> * next-method parameter for calling next matching method
>
> Note that at the moment SISC generic procedures can only operate on 
> Java objects, not Scheme objects (unless, of course, you use their Java 
> representation). That will change soon though with the introduction of 
> a SISC type system and object system.
I look forward to seeing this, but it may be confusing having two type 
systems (Java and SISC) to consider. I think
Jython has some experience dealing with these issues.

>
>
> 2) JScheme uses special syntax to access static and instance variables. 
> Field access in SISC is done by calling the Java object with a slot 
> name and optional value. SISC consequently allows one to write
>   (map 'foo (list obj1 obj2 obj3))
> to get the value of the field "foo" of three objects. I'm not sure what 
> the equivalent would look like in JScheme.
We would use a similar syntax.
 >  (map .first$ '((a b) (c d) (e f)))
  '(a c e)
The  .first$ is an accessor if called with one argument and a setter if 
called with two.

Static variables work differently and are bound to the classname, e.g. 
Math.PI$  Math.E$.

>
>
> 3) JScheme defines special Listener classes that allow the definition 
> of Java listeners in Scheme. SISC has a generic proxy mechanims that 
> allows any Java interface to be implemented in Scheme.
Jscheme can also access the proxy listener directly, but we don't yet 
have any special syntax, e.g.

one can define the following procedure which creates a proxy object 
given a list of interfaces
and a handler:

(define (make-proxy-object interfacelist handler)
   (Proxy.newProxyInstance
     (.getClassLoader (first interfacelist))
     (list->array Class.class interfacelist)
     (elf.SchemeInvocationHandler.
       (lambda (proxy method argv)
         (handler proxy method argv)))))


This can then be used to create proxy objects on the fly:
Here's an example of creating a comparator for the sorting procedure:


(define (mycompare fn)
   (make-proxy-object
     (list java.util.Comparator.class)
     (lambda (proxy method argv)
      (case (.getName method)
         (("compare")
          (let ((L (array->list argv)))
           (cond ((apply fn L) -1)
                 ((apply fn L) 0)
                 (else 1))))
         (else (.invoke method 'myCompare argv))))))

(define (mysort array)
   (java.util.Arrays.sort array (mycompare <)))
(define z #(2 7 1 8 2 8 1 8 2 8 4 5 9 0 4 5))
(mysort z)


>
> SISC's generic proxy mechanism is somewhat clunky at the moment but 
> this will improve considerably with the introduction of the type and 
> object system.
>
>
> 4) Many JScheme types map directly to standard Java types, making type 
> conversion unnecessary when objects cross the Scheme/Java divide. In 
> SISC explicit conversion is needed.

Indeed, Jscheme is probably best thought of as a Scheme-skin for Java. 
It really is programming in Java,
but the syntax is different and some higher order procedure patterns 
have been incorporated into the syntax.
We're currentlly working on a syntax for implementing Java classes using 
Jscheme, which would complete this
analogy.

>
> The JScheme solution results in incredibly concise code at the expense 
> of losing some standards compliance (e.g. mutable strings) and 
> generality. The precise reasons, straight from the SISC manual, why 
> SISC opted for explict rather than implict conversion are:
>
> * For some Scheme types, such as numbers, the mapping to Java types is 
> one-to-many, e.g. a Scheme number could be converted to a byte, short, 
> int, etc. This causes ambiguities when automatic conversion of 
> parameters is attempted.
Makes sense (but couldn't a best fit mapping be made by default, i.e. 
choose the smallest applicable type ....)

>
> * Some Java types have several corresponding Scheme types, e.g. a Java 
> array could be represented as Scheme list or vector - this causes 
> ambiguities when automatic conversion of results is attempted.

  The main problem is conversion from Scheme to Java (for procedure 
calls), i.e., what do Strings, Lists,
and Vectors maps to.  Converting back to Scheme could just do the 
reverse.

We chose to map lists to a new Java class (jsint.Pair), vectors to 
Object[], and procedures to a new Java type
jsint.Procedure. This strategy is to simply embed Scheme types in the 
Java types. This wouldn't work
for SISC as easily as Strings must be mutable. Pair's and Vectors might 
map naturally though....

>
> * Conversion carries an overhead that can be significant. For instance, 
> Java strings have to be copied "by value" to Scheme strings since the 
> former are immutable and the latter aren't. In a chained-call scenario, 
> i.e. where the results of one method invocation are passed as arguments 
> to another, the conversion is unnecessary and a wasted effort.
>
> * Conversion breaks the object identity relationship. In a chained-call 
> scenario, the identities of the objects passed to the second call are 
> different from the ones returned by the first. This causes problems if 
> the called Java code relies on the object identity being preserved.
>
> * Conversion conflicts with generic procedures. The method selection 
> mechanism employed by generic procedures relies on objects having 
> exactly one type. Automatic conversion effectively gives objects more 
> than one type - their original type and the type of the objects they 
> can be converted to. While it would be technically possible to devise a 
> method selection algorithm that accommodates this, the algorithm would 
> impose a substantial overhead on generic procedure invocation and also 
> make it significantly harder for users to predict which method will be 
> selected when invoking a generic procedure with a particular set of 
> arguments.

Conversion is indeed a tricky problem. It seems mandated by the need to 
have mutable Strings
and I don't see a way around it for SISC. For a while we toyed with the 
idea of having Scheme Symbols
get mapped to Java Strings. Both are immutable and both can be 
interned.... Maybe that would work
for SISC as well.... Then you could just use a straight embedding of all 
other Scheme objects into Java
by adding the Pair, Procedure, and Continuation classes to the public 
Java API for SISC....
Do you think this might work???

Anyway, I want to thank you for taking the time to write this 
explanation.
It helps clarify the similarities and differences. I want to look at the
way we handle define-method, perhaps we should allow it to be
used over javadot names and to let it use the " . rest)" notation
as SISC's  define-method does...

(e.g.

(define-method (.append (sb StringBuffer) . rest)
   ....)

I'm still interested in the possibility of adding javadot notation to 
SISC.
It would be a pretty simple extension and could be though of as loading
a program that lazily defines 100,000 new primitives ..... It doesn't 
strictly
violate the Scheme semantics, but it does greatly increase the size of
the namespace...

I think Geoff's suggestions was to look into a way of finding a canonical
method for converting SISC values into Scheme values (e.g. numbers
go to ints if possible, the longs if possible, then doubles, the floats, 
then
BigIntegers or BigDecimals, but inexacts always goto doubles, floats, and
BigDecimals. Converting back is more straightforward......

Thus, SISC could support a version of javadot with automatic conversion.
It might also be interesting to allow the use of Java literals (e.g. 5b, 
7.2f, 30L)
which could be converted into SISC-wrapped Java objects....

It might even be possible to have javadot and the current SISC/java 
interface
work concurrently...

---Tim---

>
>
> Matthias
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

Re: [Jscheme-devel] SISC's Scheme-to-Java interface

[Matthias R. <mat...@so...>]

Geoffrey S. Knauth wrote:
> Would it be possible to marry the type-predictability of SISC with the
> syntactic sugar of JScheme, so that type conversions need be done only
> once?
> 

I'm not quite sure what you mean by "only once". Can you elaborate, please?


Matthias.

Re: [Jscheme-devel] SISC's Scheme-to-Java interface

[Geoffrey S. K. <ge...@kn...>]

Would it be possible to marry the type-predictability of SISC with the
syntactic sugar of JScheme, so that type conversions need be done only
once?

On Sun, 2002-06-02 at 06:16, Matthias Radestock wrote:
> Hi JSchemers,
> 
> I've been following the recent "SISC and JScheme java interfaces" 
> thread. As the author of SISC's Scheme-to-Java interface I figured it 
> might be a good idea to explain some of its features and the design 
> rationale behind them.
> 
> The main differences between the SISC and JScheme approach are the 
> following:
> 
> 1) JScheme uses special syntax to invoke Java methods. SISC uses a set 
> of primitives, procedures and macros to represent Java methods as 
> generic procedures.
> 
> The special syntax approach makes JScheme code very compact and 
> readable, at the expense of chewing up a portion of the name space. In 
> SISC every Java method has to declared using
>   (define-generic foo ...)
> 
> One pervasive concept throughout SISC's generic procedure mechanism is 
> that of chaining - the chainee procedure gets invoked when the chainer 
> procedure cannot find a matching method on invocation.
> The most common place where this is used is in order to add Scheme-level 
> methods "in front" of Java methods, basically performing a kind of 
> overloading. This means you can do things like this:
> 
> (define-generic app (generic-java-procedure 'append))
> (define-method (app (next: next-method)
>                      (<jstringbuffer> buf) . rest)
>    (for-each (lambda (x) (next-method buf x)) rest)
>    buf)
> (define sb (make <jstringbuffer> (->jstring "foo")))
> (app sb (->jstring "foo") (->jint 1) (->jstring "bar"))
> ;==> stringbuffer now contains "foofoo1bar".
> 
> Note that because SISC uses no special notation for calling Java 
> methods, the same name as before can be used to call the new procedure.
> 
> Here's a list of some other interesting features of SISC generic procedures:
> 
> * they are lexically scoped; One can define the same generic procedure 
> name in multiple scopes/modules withouth them inteferring with each other.
> 
> * the first parameter is not special. It participates in method 
> selection just like any other parameter.
> 
> * The names of generic procedures by default are mapped to Java method 
> names via an "unschemification" conversion, e.g. foo-bar-baz? becomes 
> isFooBarBaz. This further blurs the distinction between doing "schemy" 
> things and "javay" things.
> 
> * constructors are generic procedures too.
> 
> * next-method parameter for calling next matching method
> 
> Note that at the moment SISC generic procedures can only operate on Java 
> objects, not Scheme objects (unless, of course, you use their Java 
> representation). That will change soon though with the introduction of a 
> SISC type system and object system.
> 
> 
> 2) JScheme uses special syntax to access static and instance variables. 
> Field access in SISC is done by calling the Java object with a slot name 
> and optional value. SISC consequently allows one to write
>    (map 'foo (list obj1 obj2 obj3))
> to get the value of the field "foo" of three objects. I'm not sure what 
> the equivalent would look like in JScheme.
> 
> 
> 3) JScheme defines special Listener classes that allow the definition of 
> Java listeners in Scheme. SISC has a generic proxy mechanims that allows 
> any Java interface to be implemented in Scheme.
> 
> SISC's generic proxy mechanism is somewhat clunky at the moment but this 
> will improve considerably with the introduction of the type and object 
> system.
> 
> 
> 4) Many JScheme types map directly to standard Java types, making type 
> conversion unnecessary when objects cross the Scheme/Java divide. In 
> SISC explicit conversion is needed.
> 
> The JScheme solution results in incredibly concise code at the expense 
> of losing some standards compliance (e.g. mutable strings) and 
> generality. The precise reasons, straight from the SISC manual, why SISC 
> opted for explict rather than implict conversion are:
> 
> * For some Scheme types, such as numbers, the mapping to Java types is 
> one-to-many, e.g. a Scheme number could be converted to a byte, short, 
> int, etc. This causes ambiguities when automatic conversion of 
> parameters is attempted.
> 
> * Some Java types have several corresponding Scheme types, e.g. a Java 
> array could be represented as Scheme list or vector - this causes 
> ambiguities when automatic conversion of results is attempted.
> 
> * Conversion carries an overhead that can be significant. For instance, 
> Java strings have to be copied "by value" to Scheme strings since the 
> former are immutable and the latter aren't. In a chained-call scenario, 
> i.e. where the results of one method invocation are passed as arguments 
> to another, the conversion is unnecessary and a wasted effort.
> 
> * Conversion breaks the object identity relationship. In a chained-call 
> scenario, the identities of the objects passed to the second call are 
> different from the ones returned by the first. This causes problems if 
> the called Java code relies on the object identity being preserved.
> 
> * Conversion conflicts with generic procedures. The method selection 
> mechanism employed by generic procedures relies on objects having 
> exactly one type. Automatic conversion effectively gives objects more 
> than one type - their original type and the type of the objects they can 
> be converted to. While it would be technically possible to devise a 
> method selection algorithm that accommodates this, the algorithm would 
> impose a substantial overhead on generic procedure invocation and also 
> make it significantly harder for users to predict which method will be 
> selected when invoking a generic procedure with a particular set of 
> arguments.
> 
> 
> Matthias
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
> 
-- 
Geoffrey S. Knauth				http://knauth.org/gsk

[Jscheme-devel] SISC's Scheme-to-Java interface

[Matthias R. <mat...@so...>]

Hi JSchemers,

I've been following the recent "SISC and JScheme java interfaces" 
thread. As the author of SISC's Scheme-to-Java interface I figured it 
might be a good idea to explain some of its features and the design 
rationale behind them.

The main differences between the SISC and JScheme approach are the 
following:

1) JScheme uses special syntax to invoke Java methods. SISC uses a set 
of primitives, procedures and macros to represent Java methods as 
generic procedures.

The special syntax approach makes JScheme code very compact and 
readable, at the expense of chewing up a portion of the name space. In 
SISC every Java method has to declared using
  (define-generic foo ...)

One pervasive concept throughout SISC's generic procedure mechanism is 
that of chaining - the chainee procedure gets invoked when the chainer 
procedure cannot find a matching method on invocation.
The most common place where this is used is in order to add Scheme-level 
methods "in front" of Java methods, basically performing a kind of 
overloading. This means you can do things like this:

(define-generic app (generic-java-procedure 'append))
(define-method (app (next: next-method)
                     (<jstringbuffer> buf) . rest)
   (for-each (lambda (x) (next-method buf x)) rest)
   buf)
(define sb (make <jstringbuffer> (->jstring "foo")))
(app sb (->jstring "foo") (->jint 1) (->jstring "bar"))
;==> stringbuffer now contains "foofoo1bar".

Note that because SISC uses no special notation for calling Java 
methods, the same name as before can be used to call the new procedure.

Here's a list of some other interesting features of SISC generic procedures:

* they are lexically scoped; One can define the same generic procedure 
name in multiple scopes/modules withouth them inteferring with each other.

* the first parameter is not special. It participates in method 
selection just like any other parameter.

* The names of generic procedures by default are mapped to Java method 
names via an "unschemification" conversion, e.g. foo-bar-baz? becomes 
isFooBarBaz. This further blurs the distinction between doing "schemy" 
things and "javay" things.

* constructors are generic procedures too.

* next-method parameter for calling next matching method

Note that at the moment SISC generic procedures can only operate on Java 
objects, not Scheme objects (unless, of course, you use their Java 
representation). That will change soon though with the introduction of a 
SISC type system and object system.


2) JScheme uses special syntax to access static and instance variables. 
Field access in SISC is done by calling the Java object with a slot name 
and optional value. SISC consequently allows one to write
   (map 'foo (list obj1 obj2 obj3))
to get the value of the field "foo" of three objects. I'm not sure what 
the equivalent would look like in JScheme.


3) JScheme defines special Listener classes that allow the definition of 
Java listeners in Scheme. SISC has a generic proxy mechanims that allows 
any Java interface to be implemented in Scheme.

SISC's generic proxy mechanism is somewhat clunky at the moment but this 
will improve considerably with the introduction of the type and object 
system.


4) Many JScheme types map directly to standard Java types, making type 
conversion unnecessary when objects cross the Scheme/Java divide. In 
SISC explicit conversion is needed.

The JScheme solution results in incredibly concise code at the expense 
of losing some standards compliance (e.g. mutable strings) and 
generality. The precise reasons, straight from the SISC manual, why SISC 
opted for explict rather than implict conversion are:

* For some Scheme types, such as numbers, the mapping to Java types is 
one-to-many, e.g. a Scheme number could be converted to a byte, short, 
int, etc. This causes ambiguities when automatic conversion of 
parameters is attempted.

* Some Java types have several corresponding Scheme types, e.g. a Java 
array could be represented as Scheme list or vector - this causes 
ambiguities when automatic conversion of results is attempted.

* Conversion carries an overhead that can be significant. For instance, 
Java strings have to be copied "by value" to Scheme strings since the 
former are immutable and the latter aren't. In a chained-call scenario, 
i.e. where the results of one method invocation are passed as arguments 
to another, the conversion is unnecessary and a wasted effort.

* Conversion breaks the object identity relationship. In a chained-call 
scenario, the identities of the objects passed to the second call are 
different from the ones returned by the first. This causes problems if 
the called Java code relies on the object identity being preserved.

* Conversion conflicts with generic procedures. The method selection 
mechanism employed by generic procedures relies on objects having 
exactly one type. Automatic conversion effectively gives objects more 
than one type - their original type and the type of the objects they can 
be converted to. While it would be technically possible to devise a 
method selection algorithm that accommodates this, the algorithm would 
impose a substantial overhead on generic procedure invocation and also 
make it significantly harder for users to predict which method will be 
selected when invoking a generic procedure with a particular set of 
arguments.


Matthias

Re: [Jscheme-devel] CVS-update

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

The new Jscheme webapp (jscheme/src/webapp) has been tested on
three servlet containers. In each case we just copy the jscheme 
directory of the webapp
folder into the "webapps" folder of the servlet container, and start up 
the servlet container.
The Date demo works in all cases. I haven't tested the others but they 
should work as well.

   tomcat,   http://jakarta.apache.org/tomcat/index.html

   Jetty,       http://jetty.mortbay.com/jetty/index.html   and

   Resin --  http://www.caucho.com/download/

It works nicely on all three on the Mac OS X. I haven't yet
tried it on windows or linuxes.

---Tim---

On Friday, May 31, 2002, at 09:00 PM, Timothy John Hickey wrote:

> Update of /cvsroot/jscheme/jscheme/src/webapp/jscheme/WEB-INF
> In directory usw-pr-cvs1:/tmp/cvs-serv30658
>
> Modified Files:
> 	web.xml
> Log Message:
> fixed bug revealed by using Jetty instead of Tomcat
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

[Jscheme-devel] CVS-update

[Timothy J. H. <tim...@us...>]

Update of /cvsroot/jscheme/jscheme/src/webapp/jscheme/WEB-INF
In directory usw-pr-cvs1:/tmp/cvs-serv30658

Modified Files:
	web.xml 
Log Message:
fixed bug revealed by using Jetty instead of Tomcat

Re: [Jscheme-devel] jscheme servlets and jetty

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

On Friday, May 31, 2002, at 08:32 PM, Timothy Hickey wrote:

> I got scheme servlet working with Jetty but I had to modify the web.xml 
> to
> replace all
>    WEB-INF/scheme/...
> by
>    /WEB-INF/scheme/....
> I haven't yet tested whether or not this change works with the
> tomcat servlet container as well.
This change is OK with tomcat, so I'll check it in.
---Tim---
>
> If this doesn't work for you, please tell me.
>
> I've attached the modified web.xml file
>
>
> Also, here is the jschemewebapp.jar file
>
> in case you couldn't build it.
>
> ---Tim---

Re: [Jscheme-devel] jscheme servlets and jetty

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

I got scheme servlet working with Jetty but I had to modify the web.xml 
to
replace all
    WEB-INF/scheme/...
by
    /WEB-INF/scheme/....
I haven't yet tested whether or not this change works with the
tomcat servlet container as well.

If this doesn't work for you, please tell me.

I've attached the modified web.xml file

Re: [Jscheme-devel] jscheme servlets and jetty

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

On Friday, May 31, 2002, at 07:29 PM, Ken Anderson wrote:

> Yes.  When we rearranged things i went back to making things from the 
> top level.  Currently, this only includes lib/jscheme.jar and 
> lib/applet.jar.
>
> Unfortunately, i won't be able to get the webapp stuff working for a 
> week or 2, though  i think were close if either of you want to try it.
I'll give it a try.
---tim---

>
> k
>
> At 06:43 PM 5/31/2002, Timothy Hickey wrote:
>
>> On Friday, May 31, 2002, at 06:31 PM, david may wrote:
>>
>>> turnsnout the jschemewebapp jar was not built. I assumed
>>> since ther was a web-inf dir I could just symlink it to the
>>> webapps dir. Didn't look to see what was there.
>>> building from the current CVS is broken.
>> We had separated the jschemewebapp build from the
>> usual build. You can build the webapp using
>>
>>   % build/make-webapp
>>
>> from the src directory.
>>
>>
>> Ken-- maybe we should have the standard build also build the
>> webapp. David's assumption that the build would build everything
>> is probably what most people will assume....
>>
>>>
>>> bash-2.05a$ pwd
>>> /home/david/jscheme/jscheme/src
>>> bash-2.05a$ ./build/bootstrap
>>> error: cannot read: src/jscheme/REPL.java
>>> 1 error
>>> Exception in thread "main" java.lang.NoClassDefFoundError: 
>>> jscheme/REPL
>>> bash-2.05a$
>>>
>>> I just backed up to the dir above src and did
>>> src/build/bootstrap
>>>
>>> but that only partialy worked so I had no jschemewebapp.jar
>>
>> Yes this need to be simplified!
>> Currently you build jscheme from above src and build the webapp
>> from inside src...... not good!
>>
>> ---Tim---
>>>
>>> davud
>>>
>>>>>>>> "Timothy" == Timothy Hickey <tim...@ma...> writes:
>>>
>>>     Timothy> On Friday, May 31, 2002, at 04:21 PM, david may wrote:
>>>
>>>>> has anyone gotten jscheme servlets working in jetty?
>>>     Timothy> I haven't tried.
>>>
>>>     Timothy> I would hope that you could just drop in a jscheme
>>>     Timothy> servlet webapp and have it work!
>>>
>>>     Timothy> Have you gotten jetty to run other Java servlets?
>>>
>>>     Timothy> ---Tim---
>>>>>  one probleme is that
>>>>> "http://java.sun.com/j2ee/dtds/web-app_2.3.dtd" does not exist
>>>>>
>>>>>
>>>>> davud
>>>>>
>>>>> _______________________________________________________________
>>>>>
>>>>> Don't miss the 2002 Sprint PCS Application Developer's
>>>>> Conference August 25-28 in Las Vegas --
>>>>> http://devcon.sprintpcs.com/adp/index.cfm
>>>>>
>>>>> _______________________________________________ Jscheme-devel
>>>>> mailing list Jsc...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>
>>
>> _______________________________________________________________
>>
>> Don't miss the 2002 Sprint PCS Application Developer's Conference
>> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>>
>> _______________________________________________
>> Jscheme-devel mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

Re: [Jscheme-devel] jscheme servlets and jetty

[Ken A. <kan...@bb...>]

Yes.  When we rearranged things i went back to making things from the top 
level.  Currently, this only includes lib/jscheme.jar and lib/applet.jar.

Unfortunately, i won't be able to get the webapp stuff working for a week 
or 2, though  i think were close if either of you want to try it.

k

At 06:43 PM 5/31/2002, Timothy Hickey wrote:

>On Friday, May 31, 2002, at 06:31 PM, david may wrote:
>
>>turnsnout the jschemewebapp jar was not built. I assumed
>>since ther was a web-inf dir I could just symlink it to the
>>webapps dir. Didn't look to see what was there.
>>building from the current CVS is broken.
>We had separated the jschemewebapp build from the
>usual build. You can build the webapp using
>
>   % build/make-webapp
>
>from the src directory.
>
>
>Ken-- maybe we should have the standard build also build the
>webapp. David's assumption that the build would build everything
>is probably what most people will assume....
>
>>
>>bash-2.05a$ pwd
>>/home/david/jscheme/jscheme/src
>>bash-2.05a$ ./build/bootstrap
>>error: cannot read: src/jscheme/REPL.java
>>1 error
>>Exception in thread "main" java.lang.NoClassDefFoundError: jscheme/REPL
>>bash-2.05a$
>>
>>I just backed up to the dir above src and did
>>src/build/bootstrap
>>
>>but that only partialy worked so I had no jschemewebapp.jar
>
>Yes this need to be simplified!
>Currently you build jscheme from above src and build the webapp
>from inside src...... not good!
>
>---Tim---
>>
>>davud
>>
>>>>>>>"Timothy" == Timothy Hickey <tim...@ma...> writes:
>>
>>     Timothy> On Friday, May 31, 2002, at 04:21 PM, david may wrote:
>>
>>>>has anyone gotten jscheme servlets working in jetty?
>>     Timothy> I haven't tried.
>>
>>     Timothy> I would hope that you could just drop in a jscheme
>>     Timothy> servlet webapp and have it work!
>>
>>     Timothy> Have you gotten jetty to run other Java servlets?
>>
>>     Timothy> ---Tim---
>>>>  one probleme is that
>>>>"http://java.sun.com/j2ee/dtds/web-app_2.3.dtd" does not exist
>>>>
>>>>
>>>>davud
>>>>
>>>>_______________________________________________________________
>>>>
>>>>Don't miss the 2002 Sprint PCS Application Developer's
>>>>Conference August 25-28 in Las Vegas --
>>>>http://devcon.sprintpcs.com/adp/index.cfm
>>>>
>>>>_______________________________________________ Jscheme-devel
>>>>mailing list Jsc...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

Re: [Jscheme-devel] jscheme servlets and jetty

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

On Friday, May 31, 2002, at 06:31 PM, david may wrote:

> turnsnout the jschemewebapp jar was not built. I assumed
> since ther was a web-inf dir I could just symlink it to the
> webapps dir. Didn't look to see what was there.
> building from the current CVS is broken.
We had separated the jschemewebapp build from the
usual build. You can build the webapp using

   % build/make-webapp

from the src directory.


Ken-- maybe we should have the standard build also build the
webapp. David's assumption that the build would build everything
is probably what most people will assume....

>
> bash-2.05a$ pwd
> /home/david/jscheme/jscheme/src
> bash-2.05a$ ./build/bootstrap
> error: cannot read: src/jscheme/REPL.java
> 1 error
> Exception in thread "main" java.lang.NoClassDefFoundError: jscheme/REPL
> bash-2.05a$
>
> I just backed up to the dir above src and did
> src/build/bootstrap
>
> but that only partialy worked so I had no jschemewebapp.jar

Yes this need to be simplified!
Currently you build jscheme from above src and build the webapp
from inside src...... not good!

---Tim---
>
> davud
>
>>>>>> "Timothy" == Timothy Hickey <tim...@ma...> writes:
>
>     Timothy> On Friday, May 31, 2002, at 04:21 PM, david may wrote:
>
>>> has anyone gotten jscheme servlets working in jetty?
>     Timothy> I haven't tried.
>
>     Timothy> I would hope that you could just drop in a jscheme
>     Timothy> servlet webapp and have it work!
>
>     Timothy> Have you gotten jetty to run other Java servlets?
>
>     Timothy> ---Tim---
>>>  one probleme is that
>>> "http://java.sun.com/j2ee/dtds/web-app_2.3.dtd" does not exist
>>>
>>>
>>> davud
>>>
>>> _______________________________________________________________
>>>
>>> Don't miss the 2002 Sprint PCS Application Developer's
>>> Conference August 25-28 in Las Vegas --
>>> http://devcon.sprintpcs.com/adp/index.cfm
>>>
>>> _______________________________________________ Jscheme-devel
>>> mailing list Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>>

[Jscheme-devel] jscheme servlets and jetty

[<da...@da...>]

has anyone gotten jscheme servlets working in jetty?

one probleme is that 
    "http://java.sun.com/j2ee/dtds/web-app_2.3.dtd"
does not exist


davud

[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
>
>

[Jscheme-devel] Jscheme GUI for SISC

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

Hi,

   I was playing with your SISC applet (very nice!)
and realized that we could use Jscheme to create an interface for
the SISC interpreter. I haven't yet created a Jscheme applet for
the SISC interpreter, but I've included below a simple Jscheme GUI.

I thought it might be of interest to the SISC community to see how
to different Java Schemes could work together. SISC seems to be
written with R5RS conformance and high performance in mind,
whereas Jscheme (jscheme.sourceforge.net) was designed to
allow easy access to Java. It can be though of as a "Scheme skin"
over Java....

Anyway, here is the little GUI
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 that all Jscheme symbols that contain a "." or a "$" are
interpreted as Java constructors, methods, fields, etc
using the Javadot notation (as shown on the jscheme.sourceforge.net 
page).


---Tim Hickey---

=================================

;; SISC Gui ...
(import "java.util.zip.*")
(import "java.io.*")
(import "sisc.*")
(import "sisc.data.*")
(import "sisc.contrib.applet.*")


;; initialize SISC
(define in (GZIPInputStream. (BufferedInputStream. (FileInputStream. 
(File. "sisc.heap")))))
(define ctx (AppContext.))
(Context.register "main" ctx)
(define r (Context.enter "main"))
(REPL.initializeInterpreter r (list->array String.class '()) in)
(Context.exit)

;; create a SISC REPL with a stream based interface
;; scheme terms sent using interpin
;; scheme results received using interpout

(define interpout (PipedOutputStream.))
(define results (BufferedReader. (InputStreamReader. (PipedInputStream. 
interpout))))
(define interpin (PipedOutputStream.))
(define schemein (PrintWriter. interpin))
(define iis (PipedInputStream. interpin))
(define dynenv
   (DynamicEnv.
    (SourceInputPort.
     (BufferedReader.
      (InputStreamReader. iis))
     "console")
    (OutputPort. (PrintWriter. interpout) #t)))
(define repl (REPL. "main" dynenv))


;; create a GUI
(jlib.Swing.load) ;; load windowing library providing high level access 
to Swing
(define results-ta (textarea 10 60))
(define userin (textarea 10 60))
(define evalbutton
   (button "eval"
     (action
      (lambda(e)
        (.append results-ta 
{\n\n---------------------------------\n[(readstring userin)] 
-->\n-----------------------------------\n})
        (.println schemein (readstring userin)) (.flush schemein)))))
(define (listener)
   (let loop ()
     (let ((x (.readLine results)))
        (.append results-ta {[x]\n}) (loop))))
(define w
   (window "test"
     (border
       (west (col 'none 'north evalbutton
                               (button "clear" (action(lambda(e) 
(.setText userin "")(.setText results-ta ""))))
         ))
       (center (vsplit 0.5 (scrollpane userin) (scrollpane 
results-ta))))))
(.pack w)
(.show w)

;; start up the REPL and the listener
(.start (Thread. listener))
  (.start repl)

[Jscheme-devel] sisc/jscheme interface

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

Hi,

I've been playing with SISC and here is a little GUI that provides 
Jscheme access to the
SISC interpreter. You need to put sisc.jar (available from 
sisc.sourceforge.net) onto
your classpath.   (You can download it directly as 
http://sisc.sourceforge.net/sisc.jar)

Note that SISC is GPL'd which places some restrictions on its use.

;; SISC Gui ...
(import "java.util.zip.*")
(import "java.io.*")
(import "sisc.*")
(import "sisc.data.*")
(import "sisc.contrib.applet.*")


;; initialize SISC
(define in (GZIPInputStream. (BufferedInputStream. (FileInputStream. 
(File. "sisc.heap")))))
(define ctx (AppContext.))
(Context.register "main" ctx)
(define r (Context.enter "main"))
(REPL.initializeInterpreter r (list->array String.class '()) in)
(Context.exit)

;; create a SISC REPL with a stream based interface
;; scheme terms sent using interpin
;; scheme results received using interpout

(define interpout (PipedOutputStream.))
(define results (BufferedReader. (InputStreamReader. (PipedInputStream. 
interpout))))
(define interpin (PipedOutputStream.))
(define schemein (PrintWriter. interpin))
(define iis (PipedInputStream. interpin))
(define dynenv
   (DynamicEnv.
    (SourceInputPort.
     (BufferedReader.
      (InputStreamReader. iis))
     "console")
    (OutputPort. (PrintWriter. interpout) #t)))
(define repl (REPL. "main" dynenv))


;; create a GUI
(jlib.Swing.load)
(define results-ta (textarea 10 60))
(define userin (textarea 10 60))
(define evalbutton
   (button "eval"
     (action
      (lambda(e)
        (.append results-ta 
{\n\n---------------------------------\n[(readstring userin)] 
-->\n-----------------------------------\n})
        (.println schemein (readstring userin)) (.flush schemein)))))
(define (listener)
   (let loop ()
     (let ((x (.readLine results)))
        (.append results-ta {[x]\n}) (loop))))
(define w
   (window "test"
     (border
       (west (col 'none 'north evalbutton
                               (button "clear" (action(lambda(e) 
(.setText userin "")(.setText results-ta ""))))
         ))
       (center (vsplit 0.5 (scrollpane userin) (scrollpane 
results-ta))))))
(.pack w)
(.show w)

;; start up the REPL and the listener
(.start (Thread. listener))
  (.start repl)

[Jscheme-devel] Re: call for code

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

Hi Paul,
Here is a Java version, but it assumes that you have jscheme.jar on the 
classpath....

    Object foo = JS.eval("(lambda(n) (lambda(i) (set! n (+ n i))))");

There are two possible reasons that I see for this not qualifying as a 
valid example:
1) it assumes a library (which would make add about 100K characters to 
the solution)
2) it interprets numbers as Java numbers and addition as Java addition
(but perhaps you want to modify your statement to be more precise about 
what
what you mean by number and increment!)

Cheers,
---Tim---


Here is the test code for this function,

/* Foo.java */

import jscheme.JS;
import jscheme.SchemeProcedure;

public class Foo {
     private static Object foo = JS.eval("(lambda(n) (lambda(i) (set! 
n (+ n i))))");

     /* call Scheme object with an integer parameter */
     private static Object FN(Object F, Object N) {return 
JS.call((SchemeProcedure)F,N);}

     public static void main(String[] args) {
         Object x = FN(foo,new Integer("355113"));
         System.out.println(FN(x,new Double("0.00001")));
         System.out.println(FN(x,new Long("100000000000000")));
         System.out.println(FN(x,new Byte("12")));
     }
}


and here is the output of running the test program.

tim% java -cp jscheme.jar:. Foo
355113.00001
1.00000000355113E14
1.00000000355125E14
  tim%


On Thursday, May 30, 2002, at 12:31 PM, Paul Graham wrote:

> Since I put Revenge of the Nerds online, a number of people
> have sent me implementations of the accumulator generator
> benchmark in other languages.  I've collected these all
> together on their own page for comparison:
>
> http://www.paulgraham.com/accgen.html
>
> If you know how to write this program in some other language
> that I don't have listed, please send it to me.
>
> (Though this seems obvious, try to be sure first that the
> code actually solves the problem.  Many of the implementations
> I've been sent have been broken or incomplete.)
>
> Thanks!
>
> --pg
>

[Jscheme-devel] CVS-update

[Ken A. <kan...@us...>]

Update of /cvsroot/jscheme/jscheme/src/jsint
In directory usw-pr-cvs1:/tmp/cvs-serv24973/src/jsint

Modified Files:
	WildImporter.java 
Log Message:
Fix for IE/NT.

[Jscheme-devel] CVS-update

[Ken A. <kan...@us...>]

Update of /cvsroot/jscheme/jscheme/src/jlib/demo
In directory usw-pr-cvs1:/tmp/cvs-serv27576

Modified Files:
	SchemeEval.scm 
Log Message:
Fix for Netscape 4.7

[Jscheme-devel] CVS-update

[Ken A. <kan...@us...>]

Update of /cvsroot/jscheme/jscheme/src/jsint
In directory usw-pr-cvs1:/tmp/cvs-serv7168/src/jsint

Modified Files:
	Import.java WildImporter.java 
Log Message:
Get eopl working again

Move try catch from Import to WildImporter to
better catch hallucinated class names that don't exist.

k

[Jscheme-devel] CVS-update

[Ken A. <kan...@us...>]

Update of /cvsroot/jscheme/jscheme/src/elf/eopl2/jscheme
In directory usw-pr-cvs1:/tmp/cvs-serv7168/src/elf/eopl2/jscheme

Modified Files:
	jscheme-init.scm 
Log Message:
Get eopl working again

Move try catch from Import to WildImporter to
better catch hallucinated class names that don't exist.

k

[Jscheme-devel] Jscheme and LL1

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

The LL1 list  (ll1...@ai...) has been discussing the notion of 
succinctness
as a measure of the power of programming languages and Paul Graham put 
out
a request for implementations of
   (lambda(n) (lambda(i) (set! n (+ n i))))
in various languages.

In Java, one could argue that the most natural way to implement this is 
using Jscheme
with the JS.eval and JS.call methods, i.e. the best way to implement a 
closure in Java
is to use  a closure....

import jscheme.JS;
import jscheme.SchemeProcedure;

   ....
public static void main(String[] args) {
   SchemeProcedure PGfun = (SchemeProcedure)   JS.eval("(lambda(n) 
(lambda(i) (set! n (+ n i))))");
   SchemeProcedure F = (SchemeProcedure)            JS.call(PGfun, new 
Integer (args[0]));
   System.out.println( ">>" + JS.call("map",F,JS.eval("(1 2 3 4 5 6 7 8 9 
10)")));
}

One can do something similar in JRuby, and presumably also in Jython.

Note however, that the need to cast objects to "SchemeProcedure" is 
tiresome.

Perhaps we should modify JS.call so that it takes an object and 
dipatches on the
type of that object x before applying it to the other arguments a,b,c,..

  if x is a  SchemeProcedure -- apply x to the other args of JS.call
  if x is a  String --> call JS.eval to get a SchemeProcedure and proceed 
as usual
       e.g. JS.call("map", JS.eval("sin"), JS.eval("'(1 2 3 4 5)")) would 
be equivalent to
               JS.eval("(map sin '(1 2 3 4 5))");
  otherwise throw a JschemeException....


Then we could write the example code above more concisely as:

   Object PGfun=JS.eval("(lambda(n) (lambda(i) (set! n (+ n i))))");
   Object F = JS.call(PGfun, new Integer(args[0]));
   System.out.println( ">>" + JS.call("map",F,JS.eval("(1 2 3 4 5 6 7 8 9 
10)")));

Even more succinctly, we could write this as:

   Object F = JS.call("(lambda(n) (lambda(i) (set! n (+ n i))))",
                                   new Integer(args[0]));
   System.out.println( ">>" + JS.call("map",F,JS.eval("(1 2 3 4 5 6 7 8 9 
10)")));

---Tim---

Re: [Jscheme-devel] Re: JScheme SchemeApplet - UC WISE Citris Project

[Dazhi L. <da...@uc...>]

Thank you very much! I'll integrate this into the listener.

Regards,
Darrel

Timothy Hickey wrote:

>
> On Sunday, May 26, 2002, at 02:15 PM, Dazhi Liu wrote:
>
>> BTW, a quick question: After user program in JScheme for a while, is
>> there an easy way to erase all user defined bindings, that is, to return
>> to the initial state of JScheme?
>>
>
>
>
> Its not too hard. At the end of this note is a procedure that creates
> a SymbolTable
> restorer. You use it as
>
> > (define z (make-state-restorer))
> ....
> > (z)
> and it will restore your state to the initial one.
>
>
>
> ;; This is a System restorer
> ;; It makes a copy of the Symbol table state which it stores in its
> returned value
> ;; > (define z (make-state-restorer))
> ;; When you later invoke the thunk
> ;; > (z)
> ;; it resets the Symbol table to its
> ;; original values (but it doesn't reset the javadot primitives as
> this would just
> ;; waste time).
>
> (define (make-state-restorer)
> (let
> ((ST0
> (java.util.Hashtable.))
> (isJavadot (lambda (x)
> (or (> (.indexOf x ".") -1) (> (.indexOf x "$") -1))))
> (enum->list
> (lambda(E)
> (let loop ((L ()))
> (if (.hasMoreElements E)
> (loop (cons (.nextElement E) L))
> L)))))
> (for-each
> (lambda(x)
> (if (not (isJavadot x)) ;; don't remember javadots!
> (.put ST0 x
> (tryCatch
> (list (.getGlobalValue (string->symbol x)))
> (lambda(e)
> ())))))
> (enum->list (.keys jsint.Symbol.symbolTable$)))
>
> (display (length (enum->list (.keys ST0))))(newline)
>
> (lambda()
> (let ((ST jsint.Symbol.symbolTable$))
> (for-each
> (lambda(x)
> (let ((v (.get ST0 x)))
> (if (equal? #null v)
> (if (not (isJavadot x))
> (begin (display x)(newline) (.remove ST x)))
> (let ((s (string->symbol x)))
> (.put ST x s)
> (if (not (null? v))
> (.setGlobalValue s (first v)))))))
> (enum->list (.keys ST)))))))
>
>
>