Scheme compilers

[James A. Crippen]

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?					  /  \