ITERATE, DEFINE and CELLs

[Chris Haynes <cth%indiana.csnet@csnet-relay.arpa>]

> 	RECURSE has the same bug that ITERATE has.  The name implies a
> certain behaviour which the process it develops may not conform to.  In
> particular, I usually use named let for loops, but I also use it for
> recursive procedures.  The advantage of named let is that its name has
> no connotations, and that it reduces the number of "reserved"
> keywords.

Recursion subsumes iteration, so RECURSE is a good name even if used for
simple iteration, but ITERATE isn't a good name when its use is not
tail-recursive.  The *disadvantage* of named let is that its name *does* have
connotation, namely local binding and *not* recursion.  Our desire to keep
down the number of keywords should not be at the expense of such confusion.

> 	How am I supposed to define things if both DEFINE! and DEFINE
> go away?

With SET!, provided one assumes that all identifiers are initially bound in
the global environment, or that SET!  can extend the global environment.
With the exception of MIT's Scheme, this is what existing systems do.  If MIT
is unwilling to change this, then we are reluctantly stuck with DEFINE.

> 	While I agree that CELLs are nice, why are they neccesary?
> They can easily be emulated with pairs, and any implementation which
> really uses them can support them optionally.

They take up half as much space as pairs, and have many fundamental uses.
They aren't *absolutely* necessary, but then neither is most of Scheme.

Chris
Dan