Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!newsreader.wustl.edu!news.starnet.net!wupost!howland.reston.ans.net!spool.mu.edu!news.cs.indiana.edu!bruggema@cs.indiana.edu
From: "Carl Bruggeman" <bruggema@cs.indiana.edu>
Subject: Re: Dynamic inheritance using Scheme?
Message-ID: <1995Feb16.112814.10713@news.cs.indiana.edu>
Organization: Computer Science, Indiana University
References: <XJAM.95Feb14002721@fir.CS.Berkeley.EDU> <59Vi1c1w165w@sytex.com> <thinmanD4265s.EKs@netcom.com>
Date: Thu, 16 Feb 1995 11:28:05 -0500
Lines: 77

In article <thinmanD4265s.EKs@netcom.com>,
Technically Sweet <thinman@netcom.com> wrote:
>
>One of the classic mistakes that Scheme compiler writers make
>is to rewrite all of the run-time in Scheme.  I wrote a Scheme
>routine to read a 3D model which took 10 minutes in compiled
>Scheme2C and < 1 sec. in the native C model-reader library.

Its sometimes rather misleading to generalize from a single data point
with one algorithm and one compiler into a sweeping statement such as
"its one of the classic mistakes that Scheme compiler writers make".

Just to offer an alternative data point, a number of features in Chez
Scheme have been migrated from C code to Scheme code over the last
five years or so and each subsequent version has been faster (there is
actually very little left that is coded in C). We have found that
there are a number of important benefits to coding as much of the
system in Scheme as possible:

  1) Portability.  Since the Scheme code is compiled using the compiler
     writer's own compiler there are never any portability problems
     when porting the Scheme portion of the system.

  2) Robustness.  Scheme offers features, such as handling stack overflow,
     that C does not.  For example, a few months ago I was working with
     very large circular objects (>20MB each) which I was able to write to
     a file without problem because the fasl writer is written in Scheme
     but which overflowed the C stack when read using the fasl reader
     which is still written in C for bootstrapping purposes (which we
     really should replace with a Scheme-coded fasl reader after boot time
     to avoid exactly these sorts of problems).

  3) Performance. Compiler limitations often become obvious when
     parts of the runtime system are moved from C to Scheme.  Much
     more importantly, however, these performance problems are likely
     to get fixed _much_ faster when the compiler writer has to live with
     them day in and day out...  For example, unless the compiler
     recognizes recursive loops and optimizes groups of letrec bound
     lambda's, it is difficult or impossible to construct a Scheme reader
     that can compete with a reader written in C using iterative constructs
     (Chez Scheme's reader is written in Scheme).  Lack of optimization
     in this area may have been part of the problem you experienced.

  4) Faster development cycle.  Languages like C do not place as great an
     emphasis on minimizing compile time as do languages like Scheme because
     they are not intended for use in an interactive environment.  For 
     example, it only take a few minutes on our DEC 3000 (Alpha processor,
     a lot of memory, and a very fast IO system) to build the
     entire system from scratch.  Last I heard it only took 16 seconds
     to compile all the Scheme source (30K+ lines) with the remaining
     time required to compile the C source (less than 5K lines), link, 
     fire up the C kernel, load the compiled scheme files, and save the
     initial heap.


In summary, IMHO, I don't think it is a mistake, let alone a "classic
mistake", for a Scheme implementer to code most of the runtime system
in Scheme.  Whenever people have to live with the results of their
work day in and day out, they tend to do a better and more thorough
job.  For example. If we required the nuclear power plant architects
and the day-to-day plant staff to live next door to their plants, the
rest of us would feel much more confident about their assurances of
safety...


Carl Bruggeman
bruggema@cs.indiana.edu










