Some things that ought to be done:
i) An preprocessor that will analyze the source in order to find the
   types of the variables that participate in an tuple operation so
   that the use will have no need for the type specifying functions.
   Also, some optimizing could be incorporated but it will be 
   done only if the user wishes so and the tuple transformations
   will be reported back. Thus, you could write programs that 
   could communicate with programs that the only thing you know about 
   is their tuple format. The preprocessor will only transform the
   tuple operation calls to the current interface which will not be
   changed. Probably, by the end of this summer, an undergraduate
   student from our group will make it. 

ii) Try a better algorithm for frequent read tuples, so that we won't
    treat them as migrated objects. In few words, when a tuple is found
    to traverse from node to node with read calls we will start sending
    copies of it for the subsequent requests. Of course, when such a tuple
    is deleted with in(), the overhead will be significant.

iii) Use a true dynamic load monitoring scheme so that eval are made 
     to the least loaded node. The Tuple Managers will have to maintain
     load info for the machines of the network and before an eval is made
     the local tuple manager will be presented with the list of nodes
     from which the one with the least load and highest preference will
     be chosen.

iv) A tuple debugger should be implemented. It doesn't seem, from
    an initial discussion we had here with some fellow students, to do
    it.

v) Perhaps, at some time the system should be written in C++. Indeed,
    it seems C++ to be ideal for the job.
