Scheme compilers

[Dwight Hughes]

James,

It might be worthwhile to take a look at Sting - an OS based on T (a
Scheme with some Lispy features developed at Yale a bit back - has a
reasonable optimizing compiler: to native code) -- full source is
available to download (LARGE: about 16-20MB zipped IIRC - the compiler
in Sting is targeted to MIPS processors I believe). You can also get the
source for T and its compiler for several processors/systems (most a bit
dated, but you should be able to find something to run it on at a
university - well enough to retarget it toward something a bit more
modern (there was a 68020 Mac version even)). Sting was in development
to fairly recently (1996?):

http://www.neci.nj.nec.com/PLS/sting.html

To get your interest up, this is their description:

"Sting is an experimental operating system designed to serve as an
efficient customizable substrate for modern programming languages. The
base language used in our current implementation is Scheme, but Sting's
core ideas could be incorporated into any reasonable high-level
language. The ultimate goal in this project is to build a unified
programming environment for parallel and distributed computing. To this
end, Sting provides mechanisms for:

creating extremely lightweight first-class asynchronous threads of
control, 
building customized scheduling, migration, and load-balancing protocols, 
specifying first-class virtual processors and virtual topologies, 
supporting a range of execution strategies from fully eager to
completely lazy evaluation, 
experimenting with diverse storage allocation policies, and 
implementing persistent multiple address spaces, and other features of a
modern micro-kernel 
software architecture such as non-blocking I/O, and user-level exception
handling."

-- Dwight


James A. Crippen wrote:
> 
> On Wed, 9 Sep 1998, Mike McDonald wrote:
> 
> >   The problem with using a C compiler as the backend is then your
> > Scheme based OS will have to be able to run a C compiler, with all
> > that entails. (Things like fork, exec, fopen, ...) Essentially, you'll
> > end up having to rewrite a chunk of Unix in Scheme. :-(
> 
> (let (asbestos-underwear #t)
>   ("
> 
> Well, I hadn't admitted it yet, but I was planning to base quite a bit of
> Schema (the OS's name, if I haven't mentioned it) off of *nix concepts
> anyway. Much of the structure would be greatly different because of the
> different language paradigm, but the abstract view would be somewhat
> familiar to a *nix hacker.
> 
> There'll probably be some things that an ordinary C & *nix hacker would
> have trouble understanding, tho.  The filesystem is more of a
> hierarchical object database, and thus all actions on files are simply
> generic functions of the file objects, with some specializations.
> 
> F'rinstance, the 'non-binary' file (alluding to the viewpoint of most FTP
> programs, either binary or human-readable text (ignoring tenex ;-)) would
> have a genc fn (or genc method if you prefer) defd in its class spec that
> would be a hook for starting the user's favorite editor, probably the
> local emacs clone.  This hook would then call some load fn for emacs which
> would decide whether to spawn a new emacs process, attach to an already
> existing one (something I've always envied VMS for, having attachment to a
> running process predefd instead of some evil IPC kluge or somesuch), or to
> open the file in a new frame (if you're using the emacs in a window
> system).  Source code of a particular language has a gen fn defined for
> compilation, then.  A bonus of that is being able to call the fn from some
> script, possibly with some special args, instead of having to constantly
> fiddle with make(1) scripts.
> 
> Lots more ideas in that vein, but essentially there's an underlying *nix
> similarity to enhance porting of software from other unixy OSes.
> 
> I know that many people don't like the idea, but this is *my* OS and I'll
> do it the way *I* want.  Hehehe...
> 
> ")); asbestos-underwear
> 
> >   There was an effort a while back trying to get the CADR code
> > released from MIT but evidentially, they can't find a copy of the
> > code. :-( Nobody was able to track down the TI code either. Since
> > Symbolics is still alive, I doubt they'd be interested in releasing
> > theirs. Although, they may have a copy of the CADR code. Hmm, I'll
> > check with reti and see.
> 
> I'd bumped into the code for the BBN Butterfly, but that's really not as
> useful as I'd like since IIRC it's just the CL interp, and not any of the
> underlying OS details.
> 
> I'd kill just to have the CADR code.  Actually I'd maim, pillage, and
> plunder to get a lispm, even a lowly old CADR beast for myself, but that's
> not likely to happen.  I don't have any money, and probably never will
> since I've my heart set on becoming a researcher.
> 
> I suppose that's part of the reason I'm trying to develop this OS, so
> people will take me somewhat seriously, and so I can have My Favorite
> Programming Environment to facilitate experimenting with user-interaction
> and compilers.
> 
> Oh, BTW I found this book [Lee 89] which explains and examines the
> generation of 'realistic compilers' (ie, close in efficiency to
> handwritten compilers) which take a specification in denotative semantics
> and generate a compiler for the language.  I'm currently reading it so I
> haven't started anything, but it sounds like a promising method of making
> a new Scheme compiler.  Of course the biggest problem will be dealing
> with the elimination of closures in run-time, but I'll find a way...
> 
> That was a bit long.  Apologies.  I'll see about making some of my notes
> more human readable.  (They're written in a personal shorthand notation
> that's hard to read without some syntax.  I could just supply the BNF and
> let someone else make a xlator, and I'd be interested in hearing comments
> on its structure, as I've tried to make something that other people could
> use efficiently.  I'll write a short paper on it for perusal.)
> 
> fnord,
> james
> 
> --
> James A. Crippen, CS/Math tenured undergrad     <<Lambda calculus       .-.
> crippenj@saturn.math.uaa.alaska.edu               uber alles!>>            \
> If the future isn't what it used to be, does that mean that the past       /\
> is subject to change in times to come?                                    /  \