Re: R4RS changes? Code?

[uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu]

On the subject of the portable code I'm looking for:

  I don't know about others who are looking, but I'm looking for
programs that allocate at least one megabyte of memory during a
run, and preferably ten or more.  I'd really like programs that
actually have a megabyte or more of data that is *live* at one
time.  I'm especially interested in programs that run for several
minutes or more on a serious workstation (compiled).  This is
for gathering locality statistics and data survival curves.

  Bob Shaw's recentPh.D. dissertation at stanford reported some similar
statistics for four large Common Lisp programs.  His programs were
the Reduce symbolic math package, a natural language understanding
program, a Common Lisp compiler (Hewlett-Packard's) compiling
itself, and the RSIM circuit simulator.

  I would be very interested in similar programs written in
portable Scheme.  Eventually I may take on porting some programs
if they don't use too many incompatible extensions, but I'd
rather not have to.

  I am interested in getting a variety of programs that are
large and/or long-running, with a preference for things that
people could actually use, rather than throwaway prototypes.  For
example, an implementation of OPS5 that actually uses the
RETE matching algorithm would be excellent.  Non-AI "plain old
programs" that do something useful would be particularly good,
since I'm looking for data that generalize beyond AI applications.

   Interactive programs would be particularly nice, if they use ASCII-
only interactions (so that I can hack up a script facility to repeatedly
run them offline).

  (The reason for all this is to gather statistics that will
guide the design of generation-based garbage collectors,
virtual memories, and copy-on-write virtual copy mechanisms
for checkpointing and side-effect isolation.  I'm implementing
a generational garbage collector for Scheme-48, and it will
be instrumented to gather the relevant statistics.  Of
course, we'll have to scale our results to compensate for
the slowness of the bytecoded Scheme-48 interpreter.  A bigger
problem is the availability of reasonable test programs --
that may require more work in porting than is involved in
implementing the gc itself.

   I may have to implement the instrumented gc for something hairier,
like Kyoto Common Lisp or T, to gather data on larger programs.
The Scheme-48 version should still be valuable, because it could
be more easily extended for simulating parallel systems, etc.)

    -- Paul

Paul R. Wilson                         
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154)   wilson%uicbert@uxc.cso.uiuc.edu
Box 4348   Chicago,IL 60680