Olin Shivers <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).
|