1. An Extensible Type System for Component-Based Design
Yuhong Xiong
Advisor: Professor Edward A. Lee
Department of Electrical Engineering and Computer Sciences
University of California at Berkeley
Type system for Ptolemy II.

2. Component-Based Design
Good for designing complex, concurrent, heterogeneous systems
Two levels of interface:
data types and
dynamic interaction: communication & execution
We propose a type system to address the constraints at these two levels
Let me first describe a general issue. We all know that component-based design is good for designing complex, heter. systems.
In this approach, when we interconnect the components to form a system, we naturally want the interfaces of components to be compatible in some sense. There are at least two levels of compatibility: data types and dynamic behavior.
For data types, if these two components communicate through some sort of message passing using typed data, the type here at this port must be compatible with the type here. For example, if this component expects to receive doubles, this one should either send out doubles, or something that can be converted to doubles. Otherwise, they won’t be able to work together.
In addition, components may have internal states, such as a parameter that the user can set to configure the component. In this case, there may also be type constraints between the type of the parameter and the type of the port.
At the behavioral level, (if components communicate through message passing,) there are many different ways for the components to send and receive messages. For example, their communication can be synchronous or asynchronous. Therefore, we also want the communication protocols used by the components to be compatible.
Because of these constraints, we need a system that allows us to specify the constraints and ensure that they are satisfied.

3. Data Type Lattice Organize all types in a lattice structure
This example lattice specifies lossless type conversion relation
General
String
Boolean
Scalar
Long
Complex
Double
Now let me get to the detailed formulation of our system. We organize all the types into a lattice structure called type lattice. This picture is an example of a type lattice. The relation in this lattice is the subtyping relation among various types. There are two kinds of subtyping relations, ad hoc subtyping and the traditional OO style subclassing. Ad hoc subtyping is essentially the type conversion relation. For example, an int can be converted to a double, and it can also be converted to complex.
Using standard lattice terminology, a type A is less than a type B if there is an upward path from A to B. For example, Int is less than Double. Two types can be incomparable. For example, Complex and Boolean are incomparable.
Int
Unknown

4. Type Compatibility Rule
sendType  receiveType
Static type checking
Type conversion
Double
Double
Complex
Double
Complex
Boolean
Given the type lattice, we can define a simple type compatibility rule, which says that the type of an output port here, must be either the same as the type of the connected input, or be less than the type of the input.
According to this rule, this topology is well typed, but this one has two type errors. In particular, the type here, Complex, is greater than the type here, and Complex and Boolean are incomparable.
These kinds of errors can be detected statically before the model executes. OK OK

5. Type Constraints
a  g
b  g
g  Complex
Int  a
g  Complex g a
Complex
Int b
Double  b
In addition to the constrains specified by the actors, the interconnection of components also imply constraints. (Constraint by type compatibility rule ) For example, across this connection, we naturally want the type here, int, to be less than or equal to the type here, alpha. Similarly, we have this, and this constraints.
Now the problem of type resolution becomes one of solving a set of inequalities. We need an algorithm for that.
Double
Efficient algorithm (Rehof & Mogensen) can find least solution

6. Structured Types (arrays and records)
Goals:
Arbitrary element types. E.g. (int)array, ((int)array)array, array of records, records containing arrays, …
Type constraints between element types and the types of other objects in system
Questions:
Order relation among structured types?
Structured types admitted by the inequality solving algorithm?
Convergence on infinite lattice?
The thing we want to support with structured types are the following:
First, we want to support arbitrary element types. For example, we can have an array of int, or an array of array of int, which can be viewed as 2-D arrays. We can also have an array of record, or record containing arrays. Basically, we want to allow the structured types to be arbitrarily nested.
Second, we want to be able to specify type constraints between the element types of a structured type, and the type somewhere else in the system. For example, we want to be to able to say: I want the type of a parameter to be an array, and I want the element type of this array to be the same as the type of another port.
To support these goals, we need to answer some questions. First, we need to give the various array and record types an order relation so that they fit into the type lattice; second, we need to check whether structured types can be handled by the inequality solving algorithm we use; in addition, since there are an infinite number of array and record types, their addition makes the type lattice infinite. So we need to check whether type resolution always converges.
Now, let’s look at these 3 questions one by one.

7. Actors Manipulating Structured Types
SequenceToArray
ArrayToSequence
ArrayAppend
ArrayElement
ArrayExtract
ArrayLength
RecordAssembler
RecordDisassembler
RecordUpdater a
a Array
SequenceToArray
item
{item: a Array, val: b Array}
RecordAssembler b
val
SequenceToArray
b Array

8. Monotonic Functions in Type Constraints
Example: AbsoluteValue Actor
Works for Int, Long, Fix, Double, Complex
Output type is the same as the input, unless input is Complex
Output type is Double when input is Complex a b
Complex
Complex f f
f(a)  b, where
f(a) = Double if a = Complex
= a otherwise
Double
Double f
Int
Int

9. Behavioral Type Data types only specify static aspects of interface
Proposal:
Capture the dynamic interaction of components in types
Use interface automata (de Alfaro & Henzinger)
Obtain benefits analogous to data typing
Call the result behavioral types
Experimental platform: Ptolemy II
The above is a type system that controls the data type at the component interface. There are other dynamic properties in the interface, such as the protocols used by a component to interact with other components. We suggest to augment the the type system to capture some of these properties, using the communication protocols as a start. To do this, we need a way to describe the communication protocols, or types, and an ordering relation between these types. We suggest to describe the protocols using automata, and the ordering relation between them is the simulation relation.
At the early stage of this work, have a starting point.

10. Interaction Semantics
Flow of control issues
in Ptolemy II, these are defined by a Director class
Communication between components
in Ptolemy II, this is defined by a Receiver class
Actor interface for execution: fire
Receiver interface for communication: put, get, hasToken

11. Models of Computation Define the interaction semantics
Implemented in Ptolemy II by a domain
Receiver + Director
Examples:
Communicating Sequential Processes (CSP): rendezvous-style communication
Process Networks (PN): asynchronous communication
Synchronous Data Flow (SDF): stream-based communication, statically scheduled
Discrete Event (DE): event-based communication
Synchronous/Reactive (SR): synchronous, fixed point semantics

12. Example: Synchronous Dataflow (SDF) Consumer Actor Type Definition
communication interface
Such actors are passive, and assume that input is available when they fire.
execution interface
Inputs:
Outputs: f
fire t
Token
hTT
Return True from hasToken
hTF
Return False from hasToken fR
Return from fire g
get hT
hasToken

13. Type Definition – Synchronous Dataflow (SDF) Domain
receiver interface
director interface

14. Type Checking – Compose SDF Consumer Actor with SDF Domain

15. Type Checking – Compose SDF Consumer Actor with DE Domain
Empty automaton indicates incompatibility
Composition type has no behaviors

16. Subtyping Relation Alternating Simulation: SDF  DE
DE Domain
SDF Domain 

17. Behavior-Level Type Lattice – Defined by Alternating Simulation
domain
polymorphic
Subtyping relation
Shown here for a few Ptolemy II domains
If an actor is compatible with a certain type, it is also compatible with the subtypes
discrete
events
communicating
sequential
processes
process
networks
synchronous
dataflow
unknown