Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!news.cs.indiana.edu!hieb@heston.cs.indiana.edu
From: hieb@heston.cs.indiana.edu (Robert Hieb)
Newsgroups: comp.lang.scheme
Subject: Re: Benchmarking Scheme
Message-ID: <1991May5.210854.7795@news.cs.indiana.edu>
Date: 6 May 91 02:08:40 GMT
References: <13905.9105041734@subnode.aiai.ed.ac.uk>
Organization: Computer Science, Indiana University
Lines: 24

jeff@aiai.edinburgh.ac.UK (Jeff Dalton) writes:

>> Date: 3 May 91 20:23:21 GMT
>> From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>

>> essentially any potentially assigned variables must be on the heap so
>> that invoking a continuation multiple times will not un-do side effects.

>If so, this looks like a very strong argument against having full
>continuations.

In practice, assigned variables in Scheme are typically "state"
variables with indefinite extent anyway, and thus not suitable for
stack placement.

The assignments in the piece of code that occasioned this side track
seem to be an artifact of an overly-literal translation from C code.
Replacing the "do" loops with "named let" loops makes it easy to
eliminate the assignments to "q" by turning it into a formal parameter
of the inner loop.  "named let" often makes it possible to remove
assignments and breaks from C-style loops.

In general, tail recursion optimization in Scheme makes it natural to
create state machines that pass (rather than assign) parameters.