5 Type System5.1 IntroductionFIGURE 5.1. An imaginary Ptolemy II applicationFIGURE 5.2. The Type Lattice5.2 Formulation5.2.1 Type ConstraintsoutType £ inType (5)FIGURE 5.3. A topology with types.5.2.2 Run-time Type Checking and Lossless Type Conversion5.3 Structured Types5.4 Implementation5.4.1 Implementation ClassesFIGURE 5.4. Classes in the data.type package.FIGURE 5.5. Classes in the actor package that support type checking.5.4.2 Type Checking and Type Resolution5.4.3 Setting Up Type Constraints5.4.4 Some Implementation Details5.5 Examples5.5.1 Polymorphic DownSample5.5.2 Fork ConnectionFIGURE 5.6. Two simple topologies with types.5.6 Actors Constructing Tokens with Structured TypesFIGURE 5.7. Conversion between sequence and array.Appendix B: The Type Resolution Algorithma = Int⁄Unknown = Int (6)Heterogeneous Concurrent Modeling and Design 113Type SystemAuthors: Edward A. LeeSteve NeuendorfferYuhong Xiong5.1 IntroductionThe computation infrastructure provided by the basic actor classes is not statically typed, i.e., theIOPorts on actors do not specify the type of tokens that can pass through them. This can be changed bygiving each IOPort a type. One of the reasons for static typing is to increase the level of safety, whichmeans reducing the number of untrapped errors [26].In a computation environment, two kinds of execution errors can occur, trapped errors anduntrapped errors. Trapped errors cause the computation to stop immediately, but untrapped errors maygo unnoticed (for a while) and later cause arbitrary behavior. Examples of untrapped errors in a generalpurpose language are jumping to the wrong address, or accessing data past the end of an array. InPtolemy II, the underlying language Java is quite safe, so errors rarely, if ever, cause arbitrary behav-ior.1 However, errors can certainly go unnoticed for an arbitrary amount of time. As an example, figure5.1 shows an imaginary application where a signal from a source is downsampled, then fed to a fastFourier transform (FFT) actor, and the transform result is displayed by an actor. Suppose the FFT actorcan accept ComplexToken at its input, and the behavior of the DownSample actor is to just pass every1. Synchronization errors in multi-thread applications are not considered here.FIGURE 5.1. An imaginary Ptolemy II applicationSourceDown-SampleFFTDisplayChapter 5 from: C. Brooks, E. A. Lee, X. Liu, S. Neuendorffer, Y. Zhao, H. Zheng "Heterogeneous Concurrent Modeling and Design in Java (Volume 2: Ptolemy II Software Architecture) ," Technical Memorandum UCB/ERL M04/16, University of California, Berkeley, CA USA 94720, June 24, 2004.114 Ptolemy IIType Systemsecond token through regardless of its type. If the Source actor sends instances of ComplexToken,everything works fine. But if, due to an error, the Source actor sends out a StringToken, then theStringToken will pass through the sampler unnoticed. In a more complex system, the time lag betweenwhen a token of the wrong type is sent by an actor and the detection of the wrong type may be arbi-trarily long.In languages without static typing, such as Lisp and the scripting language Tcl, safety is achievedby writing defensive code. When safe execution is required, code must check manually at run-timewhether the types of values are correct. In Ptolemy II, if we imitated this approach, we would have torequire actors to check the type of the received tokens before using them. For example, the FFT actorwould have to verify that the every received token is an instance of ComplexToken, or convert it toComplexToken if possible. This approach places the burden of type checking on actor developers, dis-tracting them from their development effort. It also relies on a policy that cannot be enforced by thesystem. Furthermore, since type checking is postponed to the last possible moment, the system doesnot have fail-fast behavior, so a system may generate an error message long after long after the erroroccurs, as illustrated in figure 5.1. To make matters worse, an actor may receive tokens from multiplesources. If a token with an incompatible type is received, it can be hard to identify the original sourceof the token. These potential problems can make debugging models unnecessarily difficult.To address this and other issues discussed later, Ptolemy II includes static type checking. Thisapproach is a significant extension of the simple type mechanism in Ptolemy Classic. In general-pur-pose statically-typed languages, such as C++ and Java, static type checking done by the compiler canfind many potential program errors. However, execution of a model in Ptolemy II is more similar to aninterpreted execution, and does not generally involve compilation. Nonetheless, static type checking ofthe model can still be used to detect modeling errors before actors fire. In figure 5.1, if the Source actordeclares that its output port type is String, meaning that it will send out StringTokens upon firing, thestatic type checker will identify this type conflict in the topology.In Ptolemy II, because actors may contain arbitrary Java code, static typing alone is not enough toensure type safety at run-time. For example, even if the above Source actor declares its output type tobe Complex, it may still attempt to send out a StringToken at run-time. For instance, the Source actormight contain a bug that incorrectly declares the type of a port. Hence run-time type checking is stillnecessary for the Ptolemy framework to guarantee that all actors receive tokens of an expected type.Fortunately, with the help of static type checking, run-time type checks can be performed automati-cally when a token is sent out from a port. The run-time type checker simply compares the type of aproduced token against the type of the output port. This way, a type error is detected at the earliest pos-sible time and less reliance on correct actor specifications is needed to ensure type safety. Additionally,actors can safely cast received tokens to the type of the input port without manually checking the type,making actor development easier.We have found that type checking and type safety conversions can greatly increase our confidencein making use of reusable components. However, static typing does have some drawbacks. Forinstance, it often requires actor authors to explicitly declare what type(s) of data are allowed, making itmore difficult to develop components. Ousterhout [116] also argues that static typing discourages thereuse