Olin 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. 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.
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/ >
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/ >
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: ········@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 <·······@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
Olin Shivers <·······@lambda.ai.mit.edu> writes:
| If by "simulating a lisp machine" you mean providing the benefits of a modern
| programming language
No, I don't mean that.
| 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.
However, lots of programs are unjustifyably bloated. Sometimes it is
because of poor quality of implementation. Sometimes it is because
the langauge being used is inefficient. Sometimes both. It's wrong
to just assume that bloat is paid for by the features of the langauge
or the implementation; that's hardly even true in libc anymore. As I
noted before, Oberon is a fraction of the size of Emacs and blows it
away in every respect.
| 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.
But, as you point out, most people who build scheme implementations
are not rewarded for building practical systems, so your conjecture
remains academic. On the other hand, the people who sell common lisp
haven't enjoyed notable success either, so maybe it's not so easy
after all.
(I suspect they'd all have better luck if their standard development
platform was a nice 4M 386 with a 100M disk running linux.)
| How cheap do you want? In Scsh, the underlying system is a function call
| away.
Roughly speaking, I want to replace every program in /bin, /usr/bin,
/usr/ucb, and so on, with an a.out generated by a Scheme (or ML)
compiler (or interpreter, if the original was a shell script), and I
want it to be within 10% of the size and speed and working set of the
original (shared libraries disallowed, for easier measurement).
> Roughly speaking, I want to replace every program in /bin, /usr/bin,
> /usr/ucb, and so on, with an a.out generated by a Scheme (or ML)
> compiler (or interpreter, if the original was a shell script), and I
> want it to be within 10% of the size and speed and working set of the
> original (shared libraries disallowed, for easier measurement).
I bet you can do this with Stalin.
Jeff (home page http://www.emba.uvm.edu/~qobi)
From: ········@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz)
Subject: Re: Unix tools, small and large
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,
comp.lang.functional
To: Olin Shivers <·······@lambda.ai.mit.edu>
Date: 30 Apr 1997 19:44:14 -0400
Organization: PSU CSE
Roughly speaking, I want to replace every program in /bin, /usr/bin,
/usr/ucb, and so on, with an a.out generated by a Scheme (or ML)
compiler (or interpreter, if the original was a shell script), and I
want it to be within 10% of the size and speed and working set of the
original (shared libraries disallowed, for easier measurement).
Scott, I think we agree that (1) you can't do this right now with the
technology being shipped, (2) it could be done, and (3) it would be a
great thing to do.
I developed scsh to help enable this. I do not claim scsh takes you
all the way home.
-Olin
Olin Shivers wrote:
>
> From: ········@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz)
> Subject: Re: Unix tools, small and large
> Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,
> comp.lang.functional
> To: Olin Shivers <·······@lambda.ai.mit.edu>
> Date: 30 Apr 1997 19:44:14 -0400
> Organization: PSU CSE
>
> Roughly speaking, I want to replace every program in /bin, /usr/bin,
> /usr/ucb, and so on, with an a.out generated by a Scheme (or ML)
> compiler (or interpreter, if the original was a shell script), and I
> want it to be within 10% of the size and speed and working set of the
> original (shared libraries disallowed, for easier measurement).
>
> Scott, I think we agree that (1) you can't do this right now with the
> technology being shipped, (2) it could be done, and (3) it would be a
> great thing to do.
>
> I developed scsh to help enable this. I do not claim scsh takes you
> all the way home.
> -Olin
But Jeff Siskind claims STALIN does take you there!
Why don't you port the scsh interfaces to STALIN, and
then we could use scsh for interactive development and
debugging, and STALIN as a delivery vehicle for creating
small fast executables.
Scheme-48 is really not suitable for tiny little programs.
It is bytecode based, and slurps in big libraries. It would
be quite an undertaking to make a Scheme-48 Lite, and even
then it would not create native-code executables like STALIN
does.
--
Barak Pearlmutter <···@cs.unm.edu>, http://www.cs.unm.edu/~bap/
In article <··············@galapagos.cse.psu.edu>,
Scott Schwartz <········@galapagos.cse.psu.edu.NO-SPAM> wrote:
>
>Olin Shivers <·······@lambda.ai.mit.edu> writes:
>| If by "simulating a lisp machine" you mean providing the benefits of a modern
>| programming language
>
>No, I don't mean that.
>
>| 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.
>
>However, lots of programs are unjustifyably bloated. Sometimes it is
>because of poor quality of implementation. Sometimes it is because
>the langauge being used is inefficient. Sometimes both. It's wrong
>to just assume that bloat is paid for by the features of the langauge
>or the implementation; that's hardly even true in libc anymore. As I
>noted before, Oberon is a fraction of the size of Emacs and blows it
>away in every respect.
>
>| 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.
>
>But, as you point out, most people who build scheme implementations
>are not rewarded for building practical systems, so your conjecture
>remains academic. On the other hand, the people who sell common lisp
>haven't enjoyed notable success either, so maybe it's not so easy
>after all.
>
>(I suspect they'd all have better luck if their standard development
>platform was a nice 4M 386 with a 100M disk running linux.)
>
>| How cheap do you want? In Scsh, the underlying system is a function call
>| away.
>
>Roughly speaking, I want to replace every program in /bin, /usr/bin,
>/usr/ucb, and so on, with an a.out generated by a Scheme (or ML)
>compiler (or interpreter, if the original was a shell script), and I
>want it to be within 10% of the size and speed and working set of the
>original (shared libraries disallowed, for easier measurement).