From: Ken A. <kan...@bb...> - 2004-10-06 21:34:47
|
Originally, a Java application that used JScheme used one static evaluation environment. We've changed that so that jscheme.JScheme creates a new "evaluation context". This allows a servlet container to have multiple servlets that use JScheme and they are indistinguishable from a "Pure Java application". The jscheme.JS class provides static methods that operate on a JScheme singleton. This is convenient if most of what you do is invoke Java through the Scheme side of JScheme, even if Java code invokes the Scheme side. Here are 2 situations i'm thinking about: S1: You can describe a function foo with (describe foo), and it generates an approximation to the original code by inverting the compiled version of foo. I've been thinking of using this code to make debugging more informative. This means that JScheme .java code must call into Scheme code, and this will require loading the "elf/basic.scm" package, for example. Should this be done through a separate jscheme.JScheme? I'm currently using jscheme.JS. S2: We should open up the REPL so that a user could provide a (read) (eval) and (print). Which JScheme should it use? I presume the one in JS. S3: http://schematics.sourceforge.net/schemeunit-schemeql.ps got me thinking. I have a way of writing JUnit http://www.junit.org/index.htm tests in JScheme. This requires a single Java class, which currently uses JS, and takes a thunk that performs the test. I think we need to extend this so that the class takes a thunk and a specific JScheme. I think we also need to allow a JScheme constructor to take a JScheme as an argument. k |