iterations

[Eric Dean Tribble <tribble>]

Any further thoughts about mutable iteration objects?  (what is Mu
used for (besides meditations)?).  I think I mentioned the problem of
not having Var types in Smalltalk.  Since a code fragment is worth
1024 words, here's a sample of loops that use objects that change
state for every run around the loop.

for (Iteration * it = TableIteration(table);
		it ->notEmpty();
		it ->step())
{
	blither(it ->iterand());
}
    
Actually this isn't general enough, and it might break compilers.

{	Iteration * tableIt = NEW(TableIteration(table));
	Accumulation * sumIt = NEW(SumAccumulation(0));

	while (tableIt ->notEmpty() && sumIt ->notEmpty()) {
		sumIt ->step(CAST(tableIt ->iterand(), IntegerVar));
		tableIt ->step();
	}
	sum = sumIt ->iterand();
}
    
This last structure is a bit cumbersome, but very powerful.  Notice
that it allows lots of pre-defined pieces, but the connections between
those pieces can be made inline (such as the accumulation step).  I
vaguely recall a better syntax for initializing;  one that also
preserved all the type information for cimpiling inlines.  At the very
least we can do better with pseudoconstructors and message sends:

{	TableIteration * tableIt = table->iteration();
	SumAccumulation * sumIt = sumFrom(0);
...
}

Something sneaky occurred to me:  Our implementation can know that an
iteration won't change the state of a table, for example, if it is
given a ScruTable or ImmuTable.  In those cases, it doesn't need to
copy that state of the table (or set).  When handed a MuTable, then it
copies the elements into another table.  If you have an iteration that
won't change the state, but you're applying it to a MuTable, then just
wrap it in a ScruTable to prevent the copying.  This communicates
information about permissible side-effects using the type system.

dean