Ptolemy Type System Changes

Tom Lane (Structured Software Systems) has redesigned the type resolution system in Ptolemy, fixing a number of anomalies. The key changes are that types propagate forwards through forks rather than backwards, that members of multiportholes are no longer constrained to have the same data type, and that higher-order functions in the HOF domain are evaluated in a new pre-initialization phase of execution. This solves a number of problems:
  • When a fork delivers particles to inputs of different types, the type conversion(s) will occur at the fork outputs rather than the output of the source star. This allows different conversions, or no conversion, to be performed as appropriate for each recipient. A minor disadvantage is that duplicate conversions may be performed. (This can be worked around by inserting an explicit type conversion star before the fork, if performance is critical.)
  • Input ANYTYPE multiportholes can accept particles of different types from different sources. This is an essential capability for polymorphic stars like Printer. Each member port of the multiporthole is assigned the type of the source port it's connected to.
  • In a star like Merge, the constraint that output type = input type will still constrain the input multiporthole members individually. Thus, the DE Merge will still require that all input types be the same, as it should.
  • HOF stars now rewire the schematic before porthole type assignment; this fixes a lot of problems. For example, HOFNop used to improperly constrain all the connections passing through it to be of the same type. Now, porthole type assignment is the same as it would be if the schematic were written out in full, without any HOF stars. Another benefit is that the type-specific variants of HOFSrc are no longer necessary; there is only one generic HOFSrc.

  • Last updated 04/18/97, comments to ptolemy@ptolemy.eecs.berkeley.edu.