A SISC Roadmap

I think there may be a lot of curiosity about where SISC is going in the
months ahead, so it may be time for a sort of unofficial SISC road map.  As
some of you may know, I've been heavily involved in my current startup,
Thoof (http://thoof.com), which has been sucking up my time.  However, some
time is coming available soon.

That said, there is a definite plan in addition to bug fixing in SISC which
is driven primarily by user need, but also some under the hood changes which
should make SISC simpler and more flexible as we go forward.  So, in
relative order of importance, the major changes to SISC over the next couple
of releases:

1. Migration to Andre van Tonder's macro expander (replacing psyntax).
  This gives us R6RS compatibility if we choose to have it very simply.
  More importantly, this is a smaller, cleaner expander, which is easier for
  us to understand and extend.  Better yet, its much faster than psyntax.

2. Integration of some passes of the Twobit (Larceny) compiler.  We'd be
  adopting the passes up to the code generation ones, which gives us much
  of the benefit of a modern Scheme compiler, including inlining and lambda
  lifting.

3. The ability to extend Java classes.  Work is present (and about 60%
File sisc-future.txt saved
scgmille@slate:~$ cat sisc-future.txt
I think there may be a lot of curiosity about where SISC is going in the
months ahead, so it may be time for a sort of unofficial SISC road map.  As
some of you may know, I've been heavily involved in my current startup,
Thoof (http://thoof.com), which has been sucking up my time.  However, some
time is coming available soon.

That said, there is a definite plan in addition to bug fixing in SISC which
is driven primarily by user need, but also some under the hood changes which
should make SISC simpler and more flexible as we go forward.  So, in
relative order of importance, the major changes to SISC over the next couple
of releases:

1. Migration to Andre van Tonder's macro expander (replacing psyntax).
  This gives us R6RS compatibility if we choose to have it very simply.
  More importantly, this is a smaller, cleaner expander, which is easier for
  us to understand and extend.  Better yet, its much faster than psyntax.

2. Integration of some passes of the Twobit (Larceny) compiler.  We'd be
  adopting the passes up to the code generation ones, which gives us much
  of the benefit of a modern Scheme compiler, including inlining and lambda
  lifting.

3. The ability to extend Java classes.  Work is present (and about 60%
   complete) to perform bytecode generation in order to allow the subclassing
   of Java objects by Scheme classes.  This is the one remaining hole
   in the Java-to-Scheme/Scheme-to-Java API which was previously
   satisfied only by implementing subclassing proxies more or less by hand.

4. *Some* R6RS support, or, more likely, ERR5RS support
   (http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter).
   R6RS is controversial, but there are good and less-good parts of it.
   A lot makes sense, and we'll be evaluating this and implementing what
   does make sense.


User feedback on all of this is greatly appreciated, especially #4.  We'd
love to know what you like and dislike in this list, so we can implement
future versions of SISC that will help you do what you want.  But we hope
this clears up some uncertainty.


        Scott

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/