In article <SHIVERS.95Nov5203036@lambda.ai.mit.edu>,
Olin Shivers <shivers@ai.mit.edu> wrote:
> From: Donovan Kolbly <donovan@tkg.com>
> Newsgroups: alt.lang.scheme.scsh,comp.lang.scheme
>
> > - There's a nice system being developed by Paul Wilson and another
> > guy down in Texas, [Donovan Kolbly]
>
> That would be me, and the system would be RScheme. Wow, nice to know
> Olin even knows I exist, even if he doesn't know my name!
>
> [...] RScheme looks very exciting.
For everbody who doesn't know what RScheme is, here's the basic idea:
RScheme is intended to be a fairly comprehensible, extensible implementation
of Scheme that gets good performance by compiling to C, and gets a small
footprint by using bytecodes for non-time-critical stuff.
RScheme has threads, sockets, nonblocking I/O, and other features for
Real Programming, and will soon have persistence. It also has an
object system. Currently the object system is minimal, but the system
was designed to efficiently support a much more featureful one. Everything
in the system is an object with a first-class class, including things
like integers, booleans and characters.
(The object system is designed to be mostly a subset of Dylan's---if
whoever's in charge of the new Dylan project at Apple is interested in
RScheme, they should let me know. I think it'd make a sound base for a
full Dylan implementation.)
RScheme has a real-time garbage collector with worst case pause times
on the order of a millisecond, and high availability. (That is, the
pauses aren't closely clustered, as can happen with Baker-style copying
and especially with virtual-memory-trap-based incremental collectors.
Most real-time GC's are not hard real-time; ours is the hardest
real-time GC we know of in a real implementation of a general-purpose
programming language.) This GC was developed by Mark Johnstone and me.
For compiling to C, RScheme uses Tarditi's apply-like-procedure hack,
compiling hunks of Scheme that don't do calls or backward branches into
C procedures, and gluing them together with an apply-like-procedure
that just bobs C's stack up and down by one frame. We implement our
own register set and continuation chain and stack cache, so we can
find all pointers at the C procedure calls that implement transfers
of control. (In between, the C compiler can also register allocate
variables and temporaries that don't live across C calls; this
gives us a convenient modularity---we handle simple register allocation
of the longer-lived variables, and the C compiler does the rest.)
This strategy lets us use precise garbage collection and/or swizzle
pointers for persistence purposes.
Donovan has done a great job implementing this system, and the next
release will be much improved in many ways. For scsh purposes, the
biggest differences will be in footprint size and startup times.
RScheme used to be 2 or 3 MB, because the whole system was compiled
to C code, which is fat the way we do it currently. Startup time
was on the order of seconds.
The new system is mostly compiled to bytecodes, with only the time-critical
stuff compiled to C. This gives a 1/2 MB sharable executable and a 1/2
MB heap image.
Donovan has recently implemented incremental image loading via virtual
memory tricks, so that you only fault in the heap pages you need. This
brings the startup time for small programs down to about 50msec. (Cool, huh?)
This makes RScheme suitable both for scripting and for writing the
little programs (filters, etc.) that scripts glue together.
> Actually, I am impressed enough with scsh that I want my OS interface
> to be more like its than what RScheme has now: a bunch of little hacks
> to permit me to do the occassional real piece of work I need to do.
>
> I briefly looked at porting scsh to RScheme, but scsh seemed to be
> sufficiently tied to S48's multilayer architecture to make a quick
> port impossible. RScheme still has a fairly crude scheme/C interface
> -- nothing as sophisticated as S48!
>
>A port would have the following hurdles:
>- low-level C interfaces not R4RS
>- low-level macro hacks not R4RS
>- Record structures and exceptions
Could you elaborate on this? Several issues:
- there's no C FFI in standard Scheme. Is there an emerging de facto
standard? If not, what should a Scheme ffi look like, in its broad
outlines? This is something that we've been meaning to look into
but never get around to. My impression of Guile's FFI is that it's
not very impressive. (Too closely linked to the SCM implementation
strategy.) The new C++ header reader for SCM (developed at the Media
Lab to support X and 3D graphics standards) sounds more interesting,
but I haven't looked into it.
- R4RS low-level macros seem ugly, and my impression is that they'll
never become standard---they'll either stay in the appendix or
disappear entirely. We're currently developing a syntactic extension
mechanism that's compatible with R4RS high-level macros, but is
integrated into the compiler rather than being a separate
macroexpander. (This is the right way to do it, we think, and
it will also serve as a framework for reflection on scope, e.g.,
letting us implement an object system with encapsulated objects and
more type inference, without modifying the base language compiler.)
- We don't have records, but we do have objects, which subsume the
normal functionality of records. Do you need a record facility that
lets you control the layout of fields? This shouldn't be hard.
>What you have going for you is two things:
>- higher-level code already carefully written.
> This is actually a fair amount of code.
Yes. Donovan has done an amazing job.
>- design work already done.
> Scsh represents a ton of design work, wandering around the
> Unix definition, finding out what is portable, how to represent
> it in a Scheme-like way, how to tie everything together, the
> consistent naming schemes. It took me several *years* to do this --
> and I've been hacking Unix for sixteen years and Scheme for fourteen.
> I thought I knew Unix pretty well when I started; I was wrong.
This sounds like a good fit. On the other hand, I'd guess that scsh
would be even better if it exploited an object system---even the minimal
one the we currently have.
> As another example, I would say the design of the awk macro and
> the field-reader parser library represents about two full-time weeks
> of my life.
>
> I'd be happy
> to support an effort to put the scsh interface in RScheme 0.7 (devoting
> my copious spare time to the task :-))
>
>I would be very happy to see such a thing happen.
Would you be willing to help? RScheme is not Donovan's day job. (Luckily,
he's several times more productive than most programmers, and makes steady
progress on RScheme anyway.)
>I would also love to tackle the following problem: Sit down, learn the Win32
>API. Throw out scsh, and replay the same design game for Win32. Now you have
>a nice scripting language and programming environment for the world's dominant
>OS. Then study Unix scsh and the new system, and design a set of Scheme
>libraries that abstract these two interfaces. Now if you program within these
>abstractions, your code will be totally portable across Windows and Unix.
>Some guys at DEC SRC did this with Modula-3, actually. I saw their design;
>it was pretty nice.
Yes, this seems like a good thing to do. I should look into the Modula-3
abstractions in *my* copious spare time. :-)
>It's a shame Modula-3 never successfully transited out into the real
>world.
There still some hope. For example, the Vortex project at the U of
Washington is supporting Modula-3 with the snazzy multilanguage OO
compiler system they're developing. A good backend could be a big boon
to Modula-3.
>I'm hoping most of its good ideas will survive in Java form.
Yes. Java looks pretty nice, and seems to have the best niche staked
out. (Like everybody else, I'm saying "I wish I'd done that.")
> -Olin
-- Paul
P.S. For further info on RScheme, see my home page (in my .sig, below)
and follow the links for the OOPS group and Donovan's home page.
Stop and smell the roses on the way.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|