iterations

[Mark S. Miller <mark>]

Date: Mon, 23 Oct 89 16:10:21 PDT
   From: tribble (Eric Dean Tribble)

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

Oh.  I don't know.

   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?

No, but I've got some interesting bad reasons which you'll see in a
later mail message.

   ... I'm
   using functions for initialization so I have the full type for the
   iteration and accumulation objects.  

I don't understand.  You have better abstraction with pseudo-
constructors, since they can return an instance of a type that is
hidden from the client (where that type must be a subtype of a type
that the client knows about), but NEW(Constructor (params)) provides
at least as much compile time type information & optimization
possibilities.

   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 */
	 }

Change the message name to "index" and have it defined only on the
appropriate subclass of TableIteration (IntegerTableIteration?) and
then this isn't a gross hack.  Note that, if you want to write the
above without CASTs (or casts), then "table" should be declared as an
"IntegerTable *" and "tableIt" as an "IntegerTableIteration *".  I
would think that both would be appropriate.  If this section of code
isn't meant to be specific to IntegerTables, then it should have been
the first way.

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

Can probably be done.  The major question is the possible interaction
with other PtrVar stuff we're doing to support garbage collection.
Must wait until we understand the PtrVar stuff better, and until Mr.
Hill & I can go over some relaed ideas.  Even if we figure this one
out, it may buy us absolutely nothing (and cost us complexity is the
PtrVar support).  I hadn't realized until your above example how
little it would buy us.  Notice that the original generic piece of
code calls the generic "iterand()" which must be declared as returning
a pointer to Heaper.  The only way to make use of the special
IntegerPtr would be to call some specialized alternative to
"iterand()", and as your second example shows, once we pay that price
we can use IntegerVar with full efficiency and cleanliness.

   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).

The problem is that you should treat them as variables, not as
objects, in the sense that sharing a pointer to an Iteration object
should be as rare as sharing a pointer to an "int" variable in C.  An
interesting curiousity that I believe has a deep rightness to it (that
I am a loss to explain) is that C programmers almost never heap
allocate a single persistent "int" variable which they then pass
around a pointer to.  Instead, the variables are typically held
closely and privately, and the just values are passed between
entities.  Just as it is possible for a C programmer to engage in the
above strange behavior, so should it be possible for an X++ programmer
to share a pointer to one of these Iterator objects.  What itches is
that C protects a programmer from accidently sharing a variable
instead of a value, while heap allocated Iterator objects would
encourage & hide the equivalent mistake.  If we made them Vars, we
could fix that.

   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.

Also note that copy-on-write adds no overhead to access operations.
Only to store operations.