[kepler-dev] Change in array types

[Edward A. Lee]

I have a fix for the problem Steve identified where ArrayType.convert()
was not in fact delivering an array of the type of the ArrayType on which
it is called.  Unfortunately, all our actors that use arrays were
exploiting this bug as follows:

To declare that an input port has an array type, the actor would say:

         input.setTypeEquals(new ArrayType(BaseType.UNKNOWN));

Of course, this should force the type to be exactly {unknown}, but
the bug was allowing the type to deviate from that.

The fix touches are large number of files and is not backward compatible.
Every actor that explicitly operates on arrays had to be changed.
I suspect that there are many Kepler actors that use arrays, and they
will all need to be updated.  I'm happy to do that, but I'm wondering
whether there are actors not in the repository.

Part of the fix actually significantly improves things for writing
actors that operate on arrays.  For example, ArrayToSequence wants
to declare that the input is an array and that the output has
type compatible with the array elements.  Currently, the code
to do that is pretty obtuse:

         input.setTypeEquals(new ArrayType(BaseType.UNKNOWN));
         ArrayType inputArrayType = (ArrayType) input.getType();
         InequalityTerm elementTerm = inputArrayType.getElementTypeTerm();
         output.setTypeAtLeast(elementTerm);

With my changes, it becomes:

         output.setTypeAtLeast(ArrayType.elementType(input));

This forces the input port to have an array type and the
output port to have a type at least that of the elements
of input arrays.

Correspondingly, SequenceToArray currently has obtuse type
constraint declarations.  These become:

         output.setTypeAtLeast(ArrayType.arrayOf(input));

If you just want to set a constraint that something (e.g.,
a param) be an array, do:

         param.setTypeAtLeast(ArrayType.ARRAY_BOTTOM);

As usual with type constraints, the same declarations need to
be made in the clone methods.

I guess a key question is whether to wait until after the
release to check this in... I doubt we can get copernicus
fully functional again without it...

Edward


------------
Edward A. Lee
Professor, Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal