; -*- Text -*-
; 
; $Id: TODO-RAINYDAY 2917 2006-04-27 21:25:06Z tov $


	       Rainy day projects for the Larceny hacker


Projects currently under-way (not up-to-date)
---------------------------------------------

FFIGEN version 2.
  Much has been done, much remains.  Brian Denheyer currently has
  the code (briand@zipcon.net last time we communicated).

Generic bitwise operations, as discussed at implementors' meeting.
  I've written much of this code, but it's not done.

Bytecode code generator, libraries, and interpreter.
  I've written the bytecode interpreter.  Quite a bit of design and
  coding remains to be done.  The big unknown that must be resolved
  is how to interact with native-compiled code.  (The code for the 
  BCI appears to be lost, it is not in the CVS.)

Generic functions (see Experimental/generic/*)
  We can build generic functions on top of the record system, the
  apply hooks, and a simple type facility.  Much of this code exists.

Record system (see Experimental/record.*).
  We need to tune the code, and consider a name-hiding facility for
  partial opacity.

FFI (see Ffi/*).
  Primarily call-backs and GC issues remain to be resolved -- the hard
  ones.  Much has been done, and the architecture is in place.

Simple type-propagation Pass 3 (source not available).
  Stalled due to problems with lambda-lifting.

Threads package (see Experimental/tasking for existing code).
  General design is done, code works.


Project proposals with a research flavor
----------------------------------------

C-- back-end
  Write a back-end that generates C--, either directly or
  through the usual macrology, and compare performance and code size of
  the resulting code to the that of the C and x86 back-ends.  This may
  even be somewhat publishable.  <URL:http://www.cminusminus.org/>

Java back-end
  As for the C-- back-end.  (Though Serrano and Feeley have published
  here already.)

Write barrier work / Implement Will's fast write barrier
  The write barrier is probably too slow as it is, one can solve this
  several ways.  Will's barrier is one solution.  It will reduce
  the cost of vector updates substantially (though increase space
  a little).  Other possibilities include using card marking, and
  changing the remembered set to use the Symbolics design (at least
  in the DOF collector).



Project proposals with a hack-value flavor
------------------------------------------

Portable Graphical User Interface support
  Requirements: 
    Must run on Unix, Win32, and MacOS.  Would be nice if it runs
    on or can easily be ported to BeOS and QNX.
  We need to evaluate our options:
  - vxWindows (need a C++ FFI) (mflatt says "don't do it")
  - Tk (need a C FFI) (mflatt says "don't do it")
  - a Java-based interface.  Then we need a Java FFI, which is hard,
    unless the Scheme system is actually generating java code (see below).
  - others?  (Shriram suggests Qt, but portability?)
  Tk is attractive because it's pervasive and supported; it's unattractive
  because it's pretty slow and (at least prior to version 8) had no
  GC support.

A C++ FFIGEN based on gcc-xml.
Unicode support.
A real debugger (the existing debugger should be scrapped).
A profiler.
Document the extensible I/O system.
A faster reader (maybe).
A faster printer (maybe).
Grand Larceny.
Many larceny notes.

; eof
