Rainer Joswig <joswig@lavielle.com> wrote:
+---------------
| rpw3@rigden.engr.sgi.com (Rob Warnock) wrote:
| > But as soon as you so something more complicated, SIOD's simple
| > interpreter starts to fall behind other implementations which do
| > some sort of preprocessing (compiling or "half-compiling") or
| > shallow binding of lexicals, etc..
| 
| You can do some preprocessing in SIOD, too.
| We use SIOD so that we load a toplevel file which requires
| a lot of other files (maybe upto twenty I think).
| All these files can be combined in one "preprocessed" file.
+---------------

O.k., I assume you're talking about the "csiod" tool, which reads
a bunch of forms and writes them in FASL format, prepended by a
"#!/path/to/siod" header. Yes, that helps startup times for larger
programs, but *doesn't* help the post-startup performance at all!

When I said "preprocessing", I was refering to more aggressive things,
like stack-allocating lexical vars that aren't captured in closures,
beta reductions (where it's safe to do so), etc.

But SIOD does no rewriting of S-exprs at all. It's still a "pure
interpreter". In fact, it doesn't even memoize macro expansions!
They're re-expanded every time the enclosing forms are executed.

By comparison, even though SCM is also a pure interpreter, it at
least preprocesses (well, lazily rewrites then memoizes the first
time a closure is evaluated) lexical variables into "depth+offset"
tokens to speed lookups, and expands macros only once. And MzScheme,
of course, does "real compiling" of all expressions (also doing macro
expansion once only, at compile time).


-Rob

p.s. Perhaps we should take this offline, or at least move it to
comp.lang.scheme.  ;-}

-----
Rob Warnock, 8L-846		rpw3@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
1600 Amphitheatre Pkwy.		FAX: 650-933-0511
Mountain View, CA  94043	PP-ASEL-IA