Types in the Modelica Language Types in the Modelica Language David Broman Peter Fritzson S¶ebastien Furic LinkÄoping University, Sweden LinkÄoping University, Sweden Imagine, France [email protected] [email protected] Abstract types and type systems. This may result in incom- patible compilers and unexpected behavior when Modelica is an object-oriented language designed using the language. for modeling and simulation of complex physical systems. To enable the possibility for an engineer The purpose of this paper is twofold. The ¯rst to discover errors in a model, languages and com- part gives an overview of the concept of types, pilers are making use of the concept of types and states concrete de¯nitions, and explains how this type checking. This paper gives an overview of relates to the Modelica language. Hence, the ¯rst the concept of types in the context of the Model- goal is to augment the computer science perspec- ica language. Furthermore, a new concrete syntax tive of language design among the individuals in- for describing Modelica types is given as a starting volved in the Modelica language design. The long- point to formalize types in Modelica. Finally, it is term objective of this work is to provide aids for concluded that the current state of the Modelica further design considerations when developing, en- language speci¯cation is too informal and should hancing and simplifying the Modelica language. in the long term be augmented by a formal de¯n- The intended audience is consequently engineers ition. and computer scientists interested in the founda- tion of the Modelica language. Keywords: type system; types; Modelica; simula- tion; modeling; type safety The second purpose and likewise the main con- tribution of this work is the de¯nition of a concrete 1 Introduction syntax for describing Modelica types. This syntax together with rules of its usage can be seen as a One long term goal of modeling and simulation starting point to more formally describe the type languages is to give engineers the possibility to concept in the Modelica language. To the best of discover modeling errors at an early stage, i.e., our knowledge, no work has previously been done to discover problems in the model during design to formalize the type concept of the Modelica lan- and not after simulation. This kind of veri¯ca- guage. tion is traditionally accomplished by the use of types in the language, where the process of check- The paper is structured as follows: Section 2 ing for such errors by the compiler is called type outlines the concept of types, subtypes, type sys- checking. However, the concept of types is of- tems and inheritance, and how these concepts are ten not very well understood outside parts of the used in Modelica and other mainstream languages. computer science community, which may result in Section 3 gives an overview of the three main forms misunderstandings when designing new languages. of polymorphism, and how these concepts corre- Why is then types important? Types in program- late with each other and the Modelica language. ming languages serve several important purposes The language concepts and de¯nitions introduced such as naming of concepts, providing the com- in Section 2 and 3 are necessary to understand the piler with information to ensure correct data ma- rest of the paper. Section 4 introduces the type nipulation, and enabling data abstraction. Almost concept of Modelica more formally, where we give all programming or modeling languages provide a concrete syntax for expressing Modelica types. some kind of types. However, few language spec- Finally, Section 5 state concluding remarks and i¯cations include precise and formal de¯nitions of propose future work in the area. The Modelica Association 303 Modelica 2006, September 4th – 5th D. Broman, P. Fritzson, S. Furic 2 Types, Subtyping and by the run-time system or by a language con- Inheritance struct, such as exception handling. A programming language is said to be safe if no There exist several models of representing types, untrapped errors are allowed to occur. These where the ideal model [3] is one of the most well- checks can be performed as compile-time checks, known. In this model, there is a universe V of all also called static checks, where the compiler ¯nds values, containing all values of integers, real num- the potential errors and reports them to the pro- bers, strings and data structures such as tuples, grammer. Some errors, such as array out of bound records and functions. Here, types are de¯ned as errors are hard to resolve statically. Therefore, sets of elements of the universe V. There is in¯- most languages are also using run-time checks, nite number of types, but all types are not legal also called dynamic checking. However, note that types in a programming language. All legal types the distinction between compile-time and run-time holding some speci¯c property, such as being an becomes vaguer when the language is intended for unsigned integer, are called ideals. Figure 1 gives interpretation. an example of the universe V and two ideals: real Typed languages can enforce language safety type and function type, where the latter has the by making sure that well-typed programs cannot domain of integer and codomain of boolean. cause type errors. Such a language is often called type safe or strongly typed. This checking process is called type checking and can be carried out both at run-time and compile-time. The behavior of the types in a language is ex- pressed in a type system. A type system can be described informally using plain English text, Figure 1: Schematic illustration of Universe V and or formally using type rules. The Modelica lan- two ideals. guage speci¯cation is using the former informal approach. Formal type rules have much in com- In most mainstream languages, such as Java and mon with logical inference rules, and might at C++, types are explicitly typed by stating infor- ¯rst glance seem complex, but are fairly straight- mation in the syntax. In other languages, such as forward once the basic concepts are understood. Standard ML and Haskell, a large portion of types Consider the following: can be inferred by the compiler, i.e., the compiler deduces the type from the context. This process is referred to as type inference and such a language G ` e1 : bool G ` e2 : T G ` e3 : T (t-if) is said to be implicitly typed. Modelica is an ex- G ` if e1 then e2 else e3 : T plicitly typed language. which illustrates a type rule for the following Mod- 2.1 Language Safety and Type Systems elica if-expression: if e1 then e2 else e3 When a program is executed, or in the Modelica case: during simulation, di®erent kinds of execu- A type rule is written using a number of premises tion errors can take place. It is practical to distin- located above the horizontal line and a conclusion guish between the following two types of runtime below the line. The typing judgement G ` e : T errors [2]. means that expression e has type T with respect to a static typing environment . Hence, the rule ² Untrapped errors are errors that can go un- G (t-if) states that guard e must have the type of noticed and later cause arbitrary behavior of 1 a boolean and that e and e must have the same the system. For example, writing data out of 2 3 type, which is also the resulting type of the if- bound of an array might not result in an im- expression after evaluation. This resulting type is mediate error, but the program might crash stated in the last part of the conclusion, i.e., : T. later during execution. If the language is described formally, we can at- ² Trapped errors are errors that force the com- tempt to prove the type soundness theorem [15]. putation to stop immediately; for example di- If the theorem holds, the type system is said to be vision by zero. The error can then be handled sound and the language type safe or or just safe. The Modelica Association 304 Modelica 2006, September 4th – 5th Types in the Modelica Language The concept of type safety can be illustrated by Language Type Safe Checking Robin Milner's famous statement "Well-typed pro- Standard ML yes static grams cannot go wrong"[9]. Modern type sound- Java yes static ness proofs are based on Wright and Felleisen's Common LISP yes dynamic approach where type systems are proven correct Modelica yes static1 together with the language's operational seman- Pascal almost static tics [15]. Using this technique, informally stated, C/C++ no static type safety hold if and only if the following two Assembler no - statements holds: Table 1: Believed type safety of selected lan- ² Preservation - If an expression e has a type T guages. and e evaluates to a value v, then v also has type T. 2.2 Subtyping Subtyping is a fundamental language concept used ² Progress - If an expression e has a type T in most modern programming languages. It means 0 then either e evaluates to a new expression e that if a type S has all the properties of another or e is a value. This means that a well typed type T, then S can be safely used in all contexts program never gets "stuck", i.e., it cannot go where type T is expected. This view of subtyp- into a unde¯ned state where no further eval- ing is often called the principle of safe substitution uations are possible.