namespace MuPAD {

    Object          (former Cell)	  // Those own the MTcell pointer
     - Wrapper      (former ObjectInCell)
     - ArrayWrapper (former ArrayInCell)

     - Container?
     - Integer?
     - Rational?

Helper classes:
 - Reference		// should not own the MTcell object
 - Iterator		// own or not the MTcell object?
}

- Make sure it is possible to extend the conversions to from MuPAD::Object
- At the C++ level, should lists be indexed from 1..n or 0..n-1?
- Overload assign so that Cell c = 1 does the conversion automatically.
- Get rid of Cell::at<T> which is non standard and not so much useful
  Cell.at<float>(i)     <=>  Cell.at(i).to<float>()
  Cell.at<float>(i)=1.0 <=>  Cell.at(i)=Cell(1.0)
- Should at and [] call sign() each time?
  Problem: what to do if the list has not been fully initialized yet?
  Same thing with all reference accesses
- Does "reference" operator[] really work?
- Define operators +, -, ... on Cell's
  Define operator [](Cell) on Cell's
  Make [] work with tables, sets, ..., mimicking MuPAD indexed access.
  Implement .op(x) MFop? 
  and .extop(x) which mimick MuPAD op and extop
  Iterators should follow the op order, as does for i in ... do
  output iterator (back inserter iterator for lists)
- Add a shift constant in ArrayInCell, so that one can inherits
  simultaneously from ObjectInCell<T> and ArrayInCell<S>
  Add an example of use.
- Define a container interface for the data part of a SimpleCell c:
  Interface: c.data<T>->begin(), c.data<T>->end(), c.data<T>->size(), resize
             c.data->begin()  (default to void * pointer)
  Implementation:
  class DataCell<T> {
      cell &
      T begin(), ...
  }
  Use this in *InCell, and possibly move the "shift" up in SimpleCell
- Give an example of how to store pointers to external C++ objects
  in a cell using ObjectInCell
- Make Reference<T> and Iterator<T> inherit from SimpleCell
- Split the files:
  MAPITL/Cell.h
  MAPITL/Cell_tmpl.h
  MAPITLCell.mcc		// Demonstrates how to use Cell's
  MAPITLCell.tst
  Idem for ObjectInCell, ArrayInCell, Old0_4
  The entries CXXFLAGS, LDFLAGS, SCRIPTS, LTLIBRARIES, BUILT_SOURCES,
  CLEAN_FILES can be shared between all the modules
- Make LongInCell into a complete example
- Provide a domain Dom::MAPITLClass(dynamicModule) that aleviates
  the implementation of *InCell domains
- Make Cell, ... independent from old stuff (CtoM, MtoC, ...)
  Check that all the Container functionalities are available in Cell

- Define error properly to make it practical to create error messages
  while limiting memory leaks

- Trap Exceptions and convert them into MFerror calls?
  should be taken care of by MFUNC/...

- Get rid of the string template arg in *InCell?
  Find another way to provide the domain to the dynamic module functions
  via some kind of prog::bless (see email from CCR)
  Find a way to deal with inheritance with dynamic modules functions
  Or maybe those types of data will always be "inherited from" via
  facade domains.

- Define a proper copy/reference semantic for *Cell's
  Get a review from MuPAD's experts
  Check TODO comments in the code for assignments
- Add compatibility tests of MuPAD cells with STL algorithms
- Check with MuPAD's experts if there is a way to have a destructor
  called, at least when the ref count goes to zero
  In general, find a way to reference/embed properly C++ classes
  with dynamic allocation in MuPAD cell's

- Update GLIP and the other dynamic modules to use the new interface
- Use doxygen to build reasonnable html/... documentation
- Use an ArrayInCell<int> to implement a faster generator in
  MachineIntegerListsLex (or a variation of ArrayInCell<int>
  with average constant time resize)
- Use it in generation algorithm to really achieve CAT complexity
