[kepler-dev] Re: [kepler-cvs] kepler/src/org/sdm/spa ArrayToSequence.java

[Stephen Andrew Neuendorffer]

At 11:28 AM 7/6/2004, xiaowen wrote:
>Hi Steve,
>
>I think you're asking why I don't use 
>ptolemy.domains.sdf.lib.ArrayToSequence, rather than writing my own, right?

Yes...

>I'm just noticing now that if I don't explicitly specify the type at all, 
>it seems to run, but I'll have to test that further.
This should be the normal mode of operation...  Generally speaking, you 
should not need to manually specify the types of ports.
I'm not sure why it's not working in your particular case...  As long as 
the types you specify are consistent, it should still work.


>I'm attaching a workflow for ptII4.0 that shows the problem I mean.
>
>Do you see what I might be doing wrong?

It looks like there is a bug in actors with array types where the 
declaration of type constraints assumes that types are not given
specifically.  This is a long-standing gotcha in the design of the type system.

The problem is that this pattern:

         // Set type constraints.
         input.setTypeEquals(new ArrayType(BaseType.UNKNOWN));
         ArrayType inputType = (ArrayType)input.getType();
         InequalityTerm elementTerm = inputType.getElementTypeTerm();
         output.setTypeAtLeast(elementTerm);

Creates a new object to represent the type of the input port, but when you 
set the port type manually, this code in TypedIOPort
also gets called:

     public void attributeChanged(Attribute attribute)
             throws IllegalActionException {
         if (attribute instanceof TypeAttribute) {
             Type type = ((TypeAttribute)attribute).getType();
             if (type != null) {
                 setTypeEquals(type);
             }
         } else {
             super.attributeChanged(attribute);
         }
     }

which also creates a new object.  These patterns are incompatible.
Here are two alternatives:  TypedIOPort should not call setTypeEquals, but 
should keep the type and report
sameAs type constraints in the typeConstraintList method.  Alternatively, 
type constraints should be specified symbolically, but this
is more work.  If somebody would take the initiaive in fixing this in 
Ptolemy, I would appreciate it.

Steve