Scott, I have replied only to four of the nine newsgroups to which you
originally posted. If you think this post would also be appropriate for
the tcl, perl, python, c++ or eiffel lists, feel free to forward it.
From: schwartz@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz)
Subject: Re: Shell syntax and Scheme (Reply to Chris Bitmead)
Date: 19 Apr 1997 00:17:12 -0400
Olin Shivers <shivers@lambda.ai.mit.edu> writes:
| I would further suggest that you'd be even better off punting this whole
| idea of the command-line/transcript model of shell interaction. You could
| instead use the emacs editor Edwin (written in Scheme) together with the
| Unix API provided by scsh to do a screen-oriented shell, where common
| commands would be bound to control keys, less common commands invoked from
| meta-x, and complex operations performed by entering fragments of Scheme
| and scsh process notation. Best of both worlds -- interactivity and
| programmability.
IMHO, simulating a lisp machine on top of unix is a sterile and
unsatisfying approach.
Scsh isn't simulating a LispM on top of Unix. It is hard-core in the
Unix architecture camp -- scsh's process notation supports the Unix
paradigm, and the subroutine library gives you exactly the Unix system calls.
We aren't putting something on top of Unix to hide it; we are exposing Unix.
If by "simulating a lisp machine" you mean providing the benefits of a modern
programming language -- automatic storage allocation, a broad-spectrum
scripting/systems-programming language, useful datatypes, higher-order
procedures, exceptions, modules, and so forth -- for the programmer, instead
of, say, C or tcl or sh, then, OK, guilty as charged. But I don't think of
that as "simulating a lisp machine." I just think of it as "having a
reasonable programming language for my Unix hacking."
In particular, it just doesn't make sense to
expend dozens of megabytes of ram using edwin and scsh for what should
be a small, efficient tool.
What you want from your tools is a pay-as-you-go accounting. If you write some
tiny, little program in Scheme or C that uppercases stdin to stdout, you'd
like it to compile to a tiny, little binary. If you run an emacs written in
Scheme or C, you accept that it is going to require some memory. This is
independent of language choice.
When you write a little CGI script in scsh, your script doesn't have
an emacs loaded in! You can dump out a heap image containing just the
script and the functions it calls.
However, scsh could do better in this respect than it does. The problem is
that Scheme 48 doesn't support separate compilation of modules. If it did, we
could arrange to have the run-time (append, reverse, format, the compiler,
delete-file, awk, regexp-matchers, and on and on) get faulted in to the
running system on-demand, module by module -- the Scheme module equivalent of
dynamic libs. You'd fault modules in shared/read-only, so you'd share the
module's code and other read-only parts with other Unix processes using the
same module.
I have been waiting for some time to be able to do this, but the S48 authors
have yet to do separate compilation. They are overworked academics, so it's
hard to do all the implementation things that need doing. As a result, when
you run scsh, you get all the basic run-time loaded in. However... the new
static heap linker means you can at least move all those bits into the text
segment of your process, where they will be shared across processes, not
copied back and forth by the GC, and just quietly live on disk until you want
them. This is a huge improvement.
Note that this is purely an implementation issue. Anyone with the time and
skill could sit down and make separate compilation happen for Scheme 48. It
isn't really a design issue. In principal, you could pay-as-you-go with this
setup.
Much better results come from mechanisms in the style of Oberon, such
as Wily, where inexpensive mechanisms are used to integrate the user
interface with the beauty of the underlying system. (As usual, perl,
tcl, and python are popular languages among wily users.)
<URL: ftp://ftp.cs.su.oz.au/gary/wily/ >
How cheap do you want? In Scsh, the underlying system is a function call
away.
If you want a command interpreter with lisp-like properties, there are
shells, such as es, which do the job, and are orders of magnitude
smaller than scsh. <URL: ftp://ftp.white.toronto.edu/pub/es/ >
And also much less powerful.
-Olin
|