iterations

[Eric Dean Tribble <tribble>]

(what is Mu used for (besides meditations)?).  

   I'd like to use it for MuTable (and MuSet, see previous mail message).
   I think, given the other names, this is clearer for a table kind of
   thing with a "store" operation than simply "Table".  Admittedly,
   "MuSet" isn't as cute as "SetBang".

I meant, what is the variable normally associated with in physics (if
anything).

   That's not proper C++.

I actually meant:

      for (Iteration * it = NEW(TableIteration(table));
		      it ->notEmpty();
		      it ->step())
      {
	      blither(it ->iterand());
      }

I think the iteration objects need to be stored in the heap because
they can be handed in from the outside.  We can certainly implement a
wierd pointer type that looks like a IterationVar even though the real
object is stored in the heap.  Is there a good reason to do this?

I'll fix the next code fragment.  I did in fact mean what you
eventually parsed.  I'll give two version of the code, one that uses
basic iterand stuff, one that uses a SumAccumulation specific protocol.

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

	      while (tableIt ->notEmpty() && sumIt ->notEmpty()) {
		      sumIt ->step(CAST(Integer, tableIt ->iterand()));
		      tableIt ->step();
	      }
	      sum = CAST(Integer, sumIt ->iterand()) ->asIntegerVar();
      }

and the optimized version (just to show that it can be done).  I'm
using functions for initialization so I have the full type for the
iteration and accumulation objects.  Note the overloaded
implementation of 'step' for SummAccumulation (to handle IntegerVars).
And the special integrVarIterand message (a gross hack, to be sure).

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

	      while (tableIt ->notEmpty() && sumIt ->notEmpty()) {
		      sumIt ->step(tableIt ->integerVarIterand());
		      tableIt ->step();
	      }
	      sum = sumIt ->sum();	/* special for the sum accumulation */
      }

   I know you're going to say the only reason I got confused here is that
   I haven't fixed the "IntegerVar" / "Integer *" duality, but I can't
   figure out how to.  I think we're stuck with this duality as it is
   currently defined.

My fault.  However what about the fix that separates IntegerPtrs from
IntegerVars and makes IntegerPtrs as efficient as IntegerVars?

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

   I also like it better with the message sends & pseudo-constructors.
   I'm not sure I understand the point you're trying to make though.  Is
   the point that mutable iterators variables can be Heapers instead of
   Vars, and so ease the translation burden?  This is correct and a good
   idea, but I'm not sure if I'm answering the question.

I want you to spot where it itches.  There's something bugging me
about this scheme.  Also note above that Iteration objects have to be
on the heap (even if they don't look like it).

   Works fine on an ImmuTable, but there you don't need to be sneaky.
   Doesn't work on a ScruTable.  What we need to know is whether anything
   in the body of the loop could be changing the underlying table.  Even
   if the view of table that we constructed the Iterator from is a
   read-only view, the body of the loop could be changing the table being
   viewed through another access channel.

Yes.

   What's wrong with copy-on-write?  When we could have gotten away with
   one of these sneaky schemes, a copy-on-write scheme wouldn't have
   copied, and been about as efficient.

The expense for copy-on-write increases as the granularity decreases.
For tiny Tables,  a copy-on-write flag takes lots of space.  Is there
a cleverer implementation?  The checking time is also quite expensive.
Since we'd be using Tables for lots of data-manipulation, the
extremely few situations requiring copying would not be worth the
speed hit for all the other loops.  Imagine doubling the access time
for each character in a composition routine.  Hmmm.  WordVectors are
ImmuTables aren't they.  Hmmm.  Maybe I agree.

dean