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 Γ ` e1 : bool Γ ` e2 : T Γ ` e3 : T (t-if) is said to be implicitly typed. Modelica is an ex- Γ ` 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 Γ ` 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- Γ (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. [12]. In this case, S is said to be a subtype of T, which is written as Note that the above properties of type safety cor- S <: T (1) responds to our previous description of absence of untrapped errors. For example, if a division by This relation can be described using the following zero error occurs, and the semantics for such event important type rule called the rule of subsumption. is unde ned, the progress property will not hold, i.e., the evaluation gets ”stuck”, or enters an un- Γ ` t : SS <: T (t-sub) de ned state. However, if dynamic semantics are Γ ` t : T de ned for throwing an exception when the divi- sion by zero operation occurs, the progress prop- The rule states that if S <: T, then every term2 erty holds. t of type S is also a term of type T. This shows a For the imperative and functional parts of the special form of polymorphism, which we will fur- Modelica language, the safety concept corresponds ther explore in Section 3. to the same methodology as other languages, such as Standard ML. However, for the instan- 2.3 Inheritance tiation process of models, the correspondence to Inheritance is a fundamental language concept the progress and preservation properties are not found in basically all class based Object-Oriented obvious. (OO) languages. From an existing base class, a Table 1 lists a number of programming lan- new subclass can be created by extending from guages and their properties of being type safe the base class, resulting in the subclass inheriting [10][2]. The table indicates if the languages are all properties from the base class. One of the main primarily designed to be checked statically at purposes with inheritance is to save programming compile-time or dynamically at run-time. How- ever, the languages stated to be statically type 1One can argue whether Modelica is statically or dynam- checked typically still perform some checking at ically checked, depending on how the terms compile-time and run-time are de ned. Furthermore, since no exception runtime. handling is currently part of the language, semantics for Although many of the languages are commonly handling dynamic errors such as array out of bound is not believed to be safe, few have been formally proven de ned in the language and is therefore considered a com- piler implementation issue. to be so. Currently, ML [9] and subsets of the Java 2The word term is commonly used in the literature as language [14] [7] has been proven to be safe. an interchangeable name for expression.
The Modelica Association 305 Modelica 2006, September 4th – 5th D. Broman, P. Fritzson, S. Furic and maintenance e orts of duplicating and reading A famous example, originally stated by Alan duplicates of code. Inheritance can in principle be Snyder [13], illustrates the di erence between sub- seen as an implicit code duplication which in some typing and inheritance. Three common abstract circumstances implies that the subclass becomes a data types for storing data objects are queue, stack subtype of the type of the base class. and dequeue. A queue normally has two opera- Figure 2 shows an example3 where inheritance tions, insert and delete, which stores and returns is used in Modelica. A model called Resistor object in a rst-in- rst-out (FIFO) manner. A extends from a base class TwoPin, which includes stack has the same operations, but are using a two elements v for voltage and i for current. Fur- last-in- rst out (LIFO) principle. A dequeue can thermore, two instances p and n of connector Pin operate as both a stack and a queue, and is nor- are public elements of TwoPin. Since Resistor mally implemented as a list, which allows inserts extends from TwoPin, all elements v, i, p and and removals at both the front and the end of the n are ”copied” to class Resistor. In this case, list. the type of Resistor will also be a subtype of Figure 3 shows two C++ classes modeling the TwoPin’s type. properties of a dequeue and a stack. Since class Dequeue implements the properties also needed connector Pin for a stack, it seems natural to create a sub- SI.Voltage v; class Stack that inherits the implementation flow SI.Current i; from Dequeue. In C++, it is possible to use end Pin; so called private inheritance to model inheritance with an exclude operation, i.e., to inherit some, but partial model TwoPin SI.Voltage v; not all properties of a base class. In the exam- SI.Current i; ple, the public methods insFront, delFront, Pin p, n; and delRear in class Dequeue are inherited to equation be private in the subclass Stack. However, by v = p.v - n.v; adding new methods insFront and delFront 0 = p.i + n.i; in class Stack, we have created a subclass, which i = p.i; has the property of a stack by excluding the end TwoPin; method delRear. Stack is obviously a subclass model Resistor extends TwoPin; class Dequeue{ parameter SI.Resistance R=100; public: equation void insFront(int e); R*i = v; int delFront(); end Resistor; int delRear(); };
Figure 2: Example of inheritance in Modelica, class Stack : private Dequeue{ where a new subclass Resistor is created by ex- public: tending the base class TwoPin. void insFront(int e) {Dequeue::insFront(e);} However, a common misunderstanding is that sub- int delFront() typing and inheritance is the same concept [10]. {return Dequeue::delFront();} A simple informal distinction is to say that ”sub- }; typing is a relation on interfaces”, but ”inheri- tance is a relation on implementations”. In the Figure 3: C++ example, where inheritance does resistor example, not only the public elements not imply a subtype relationship. v, i, p and n will be part of class Resistor, but also the meaning of this class, i.e, the equa- of Dequeue, but is it a subtype? The answer is tions v = p.v - n.v, 0 = p.i + n.i and no, since an instance of Stack cannot be safely i = p.i. used when Dequeue is expected. In fact, the op- posite is true, i.e., Dequeue is a subtype of Stack 3These classes are available in the Modelica Standard Library 2.2, but are slightly modi ed for reasons of read- and not the other way around. However, in the ability. following section we will see that C++ does not
The Modelica Association 306 Modelica 2006, September 4th – 5th Types in the Modelica Language treat such a subtype relationship as valid, but the declarations are used. Type equivalence is con- type system of Modelica would do so. trolled by checking that the same declared name is used. Furthermore, the subtype relation in 2.4 Structural and Nominal Type Sys- OO languages is checked by validating the inheri- tems tance order between classes. The C++ language is mainly using a nominal type system, even if parts During type checking, regardless if it takes place at of the language does not obey the strict nominal compile-time or run-time, the type checking algo- structure. rithm must control the relations between types to Consider the listing in Figure 4, which illus- see if they are correct or not. Two of the most fun- trates a C++ model similar to the resistor ex- damental relations are subtyping and type equiva- ample earlier given as Modelica code in Figure 2. lence. In this case, Resistor is a subclass of TwoPin Checking of type equivalence is the single most and the type of Resistor is therefore also a common operation during type checking. For ex- subtype of TwoPin’s type. However, the type ample, in Modelica it is required that the left and of Inductor is not a subtype to the type of right side of the equality in an equation have the TwoPin, since Inductor does not inherit from same type, which is shown in the following type TwoPin. Moreover, Resistor2 is not type rule. equivalent to Resistor even if they have the same structure and inherits from the same base Γ ` e : T Γ ` e : T 1 2 (t-equ) class, since they are opaquely declared. Γ ` e1= e2 : Unit
Note that type equivalence has nothing to do with class Pin{ equivalence of values, e.g., equation 4 = 10 is public: type correct, since integers 4 and 10 are type float v, i; equivalent. However, this is of course not a valid }; equation, since the values on the right and left side class TwoPin{ are not the same. public: The Unit type (not to confuse with physical TwoPin() : v(0),i(0){}; units), shown as the resulting type of the equa- float v, i; tion, is often used as a type for uninteresting result Pin p, n; values. }; A closely related concept to type equivalence is class Resistor : public TwoPin{ type declaration, i.e., when a type is declared as public: a speci c name or identi er. For example, the Resistor() : r(100) {}; following Modelica record declaration float r; record Person }; String name; Integer age; class Resistor2 : public TwoPin{ end Person; public: Resistor() : r(200) {}; declares a type with name Person. Some lan- float r; guages would treat this as a new unique type that }; is not equal to any other type. This is called class Inductor{ opaque type declaration. In other languages, this public: declaration would simply mean that an alternative TwoPin() : v(0),i(0){}; name is given to this type. However, the type can float v, i; also be expressed by other names or without any Pin p, n; name. This latter concept is commonly referred const float L; as transparent type declaration. }; In a pure nominal type system, types are com- pared (subtyping and type equivalence) by using Figure 4: Resistor inheritance example in the names of the declared types, i.e., opaque type C++.
The Modelica Association 307 Modelica 2006, September 4th – 5th D. Broman, P. Fritzson, S. Furic
In a structural type system [12], declarations are posite is not always true. Recall the Dequeue introducing new names for type expressions, but example listed in Figure 3. The class Stack has no new types are created. Type equivalence and a subclass relation to Dequeue, but a subtype re- subtype relationship is only decided depending on lation cannot be enforced, due to the structure of the structure of the type, not the naming. the class. The converse could be true, but the The Modelica language is inspired by the type type system of C++ would not allow it, since it system described by Abadi and Cardelli in [1] is nominal and subtype relationships are based on and is using transparent type declarations, i.e., names. Hence, a structural type system can be Modelica has a structural type system. Con- seen as more expressive and exible compared to sider the Resistor example given in Figure 2 a nominal one, even if both gives the same level of and the two complementary models Inductor language type safety. and Resistor2 in Figure 5. Here, the same relations holds between TwoPin and Resistor, i.e., that the type of Resistor is a subtype of 3 Polymorphism TwoPin’s type. The same holds between TwoPin A type system can be monomorphic in which each and Resistor2. However, now Resistor and value can belong to at most one type. A type sys- Resistor2 are type equivalent, since they have tem, as illustrated in Figure 1, consisting of the the same structure and naming of their public distinct types function, integer, real, and boolean elements. Furthermore, the type of Inductor is a monomorphic type system. Conversely, in a is now a valid subtype of TwoPin’s type, since polymorphic type system, each value can belong Inductor contains all public elements (type and to many di erent types. Languages supporting name) of the one available in TwoPin. polymorphism are in general more expressive com- pared to languages only supporting monomorphic model Resistor2 types. The concept of polymorphism can be han- extends TwoPin; dled in various forms and have di erent naming parameter SI.Resistance R=200; equation depending on the paradigm where it is used. Fol- R*i = v; lowing John C. Mitchell’s categorization, polymor- end Resistor; phism can be divided into the following three main categories [10]: model Inductor Pin p, n; Subtype Polymorphism SI.Voltage v; SI.Current i; Parametric Polymorphism parameter SI.Inductance L=1; equation Ad-hoc Polymorphism L*der(i) = v; end Inductor; There are other similar categorizations, such as Cardelli and Wegner’s [3], where the ad-hoc cat- Figure 5: Complementary Inductor and egory is divided into overloading and coercion at Resistor2 models to the example in Figure 2. the top level of categories.
It is important to stress that classes and types in 3.1 Subtype Polymorphism a structural type system are not the same thing, which also holds for Modelica. The type of a class Subtyping is an obvious way that gives polymor- represents the interface of the class relevant to the phic behavior in a language. For example, an in- language’s type rules. The type does not include stance of Resistor can be represented both as an implementation details, such as equations and al- TwoPin type and a Resistor type. This state- gorithms. ment can also be shown according to the rule of Note that a nominal type system is more re- subsumption (t-sub) described in Section 2.2. strictive than a structural type system, i.e., two When a value is changed from one type to some types that have a structured subtype relation can supertype, it is said to be an up-cast. Up-casts always have a subtype relation by names (if the can be viewed as a form of abstraction or infor- language’s semantics allows it). However, the op- mation hiding, where parts of the value becomes
The Modelica Association 308 Modelica 2006, September 4th – 5th Types in the Modelica Language invisible to the context. For example, an up-cast 3.2 Parametric Polymorphism from Resistor’s type to TwoPin’s type hides the parameter R. Up-casts are always type safe, The term parametric polymorphism means that i.e., the run-time behavior cannot change due to functions or classes can have type parameters, to the upcast. which types or type expressions can be supplied. The term parametric polymorphism is often used However, for subtype polymorphism to be use- in functional language communities, while people ful, typically types should be possible to down- related to object-oriented languages tend to use cast, i.e., to change to a subtype of a type’s value. the term generics. Consider function Foo The C++ template mechanism is an exam- function Foo ple of explicit parametric polymorphism, where input TwoPin x; the type parameter must be explicitly declared. output TwoPin y; Consider for example Figure 6, where a tem- end Foo; plate function swap is implemented. The type parameter T must be explicitly stated when 4 where we assume that down-casting is allowed . It declaring the function. However, the type ar- is in this case valid to pass either a value of type gument is not needed when calling the func- TwoPin (type equivalence) or a subtype to the tion, e.g., both int x,y; swap(x,y); and type of TwoPin. Regardless if a value of TwoPin’s float i,j; swap(i,j) are valid usage of the or Inductor’s type is sent as input to the func- function. tion, a value of TwoPin’s type will be returned. It is not possible for the static type system to know template
The Modelica Association 309 Modelica 2006, September 4th – 5th D. Broman, P. Fritzson, S. Furic
Modelica can be seen to support a limited ver- distinction between overloading and type coer- sion of parametric polymorphism, by using the re- cion is not always clear, and the two concepts are declare construct on local class declarations. strongly related. Consider the following four ex- pressions of multiplication [3]: 3.3 Ad-hoc Polymorphism 7 * 9 //Integer * Integer 6.0 * 9.1 //Real * Real In parametric polymorphism the purpose is to de- 6 * 5.2 //Integer * Real clare one implementation that can be used with 6.0 * 8 //Real * Integer di erent types of arguments. Ad-hoc polymor- All four of these expressions are valid Modelica ex- phism, by contrast, allows a polymorphic value to pressions, but they can in the context of coercion be used di erently depending on which type the and overloading be interpreted in three di erent value is viewed to have. ways: There are several language concepts that fall under the concept of ad-hoc polymorphism [3], The multiplication operator is overloaded where Overloading and Coercion are most notable. four times, one for each of the four expres- Other related concepts that also fall under this sions. category are Java’s instanceOf concept and dif- ferent form of pattern matching [12]. The operator is overloaded twice; one for each of the the rst two expressions. If the argu- 3.3.1 Overloading ments have di erent types, i.e., one is Real and the other one Integer, type coercion is A symbol is overloaded if it has two or more mean- rst performed to convert the arguments to ings, which are distinguished by using types. That Real. is, a single function symbol or identi er is associ- ated with several implementations. Arguments are always implicitly converted to An example of overloading that exists in many Real, and the operator is only de ned for programming languages is operator overloading Reals. for built in types. For example, the symbol + Type conversions can also be made explicit, i.e., is using in x notation and have two operands as- code is inserted manually by the programmer that sociated with it. The type of these operands de- converts the expression to the correct type. cide how the operation should be carried out, i.e., In Modelica, implicit type conversion is used which implementation that should be used. when converting from Integer to Real. Of the Overloading can take place at either compile- three di erent cases listed above, the second one time or at run-time. Overloading used at run- applies to the current Modelica 2.2 standard. time is often referred to as dynamic lookup[10], dy- namic dispatch or multi-method dispatch. In most cases, the single term overloading refers to static 4 Modelica Types overloading taking place at compile-time. The dis- tinction becomes of course vague, if the language In the previous sections we described di erent as- is interpreted and not compiled. pects of types for various languages. In this sec- Another form of overloading available in some tion we will present a concrete syntax for describ- languages is user-de ned function overloading, ing Modelica types, followed by rules stating legal where a function identi er can represent sev- type expressions for the language. eral implementations for di erent type arguments. The current Modelica language speci cation Modelica is currently not supporting any form of [11] speci es a formal syntax of the language, but user de ned overloading. the semantics including the type system are given informally using plain English. There is no ex- plicit de nition of the type system, but an implicit 3.3.2 Coercion description can be derived by reading the text de- Another form of ad-hoc polymorphism is coer- scribing relations between types and classes in the cion or implicit type conversion, which is run-time Modelica speci cation. This kind of implicit spec- conversion between types, typically performed by i cation makes the actual speci cation open for code automatically inserted by the compiler. The interpretation, which may result in incompatible
The Modelica Association 310 Modelica 2006, September 4th – 5th Types in the Modelica Language compilers; both between each other, but also to What is the type of model B? Furthermore, if B the speci cation itself. Our work in this section was used and instantiated as a component in an- should be seen as a rst step to formalize what a other model, e.g., B b;, what would the resulting type in Modelica actually is. Previous work has type for element b be? Would the type for B and been performed to formally specify the semantics b be the same? The answer to the last question is of the language [8], but without the aim to more de nitely no. Consider the following listing, which precisely de ne the exact meaning of a type in the illustrates the type of model B. language. model classtype //Class type of model B Why is it then so important to have a precise public parameter Real objtype s; de nition of the types in a language? As we have public connector classtype described earlier, a type can be seen as an interface flow Real objtype p; to a class or an object. The concept of interfaces nonflow Real objtype q; forms the basis for the widely accepted approach end C; of separating speci cation from implementation, protected Real objtype x; end which is particularly important in large scale de- velopment projects. To put it in a Modelica mod- This type listing follows the grammar syntax eling context, let us consider a modeling project listed in Figure 7. The rst thing to notice is that of a car, where di erent modeling teams are work- the name of model B is not visible in the type. Re- ing on the wheels, gearbox and the engine. Each call that Modelica is using a structural type sys- team has committed to provide a set of speci c at- tem, where the types are determined by the struc- tributes for their component, which speci es the ture and not the names, i.e., the type of model B interface. The contract between the teams is not has nothing to do with the name B. However, the violated, as long as the individual teams are fol- names of the elements in a type are part of the lowing this commitment of interface (the speci ca- type, as we can see for parameter s and variable tion) by adding / removing equations (the imple- x. mentation). Since the types state the interfaces in The second thing to observe is that the equa- a language with a structural type system, such as tion part of the model is missing in the type def- Modelica, it is obviously decisive that they have a inition. The reason for this is that equations and precise de nition. algorithms are part of the implementation and not Our aim here is to de ne a precise notation of the model interface. Moreover, all elements s, C types for a subset of the Modelica language, which and x are preserved in the type, but the keywords can then further be extended to the whole lan- model, connector and basic type Real are fol- guage. Since the Modelica language speci cation lowed by new keywords classtype or objtype. is open for interpretation, the presented type def- This is one of the most important observations to inition is our interpretation of the speci cation. make regarding types in a class based system us- ing structural subtyping and type equivalence. As 4.1 Concrete Syntax of Types we can see in the example, the type of model B is a class type, but parameter s is an object type. Now, let us study the types of some concrete Mod- Simply stated: A class type is the type of one B elica models. Consider the following model , of Modelica’s restricted classes, such as model, which is rather uninteresting from a physical point connector, record etc., but an object type is of view, but demonstrates some key concepts re- the type of an instance of a class, i.e., an object. garding types. Now, the following shows the object type of b, model B where b represents an instance of model B: parameter Real s=-0.5; connector C model objtype //Object type of b flow Real p; parameter Real objtype s; Real q; end end C; Obviously, both the type of connector C and protected Real x(start=1); variable x have been removed from the type of b. equation The reason is that an object is a run-time entity, der(x) = s*x; where neither local classes (connector C) nor pro- end B; tected elements (variable x) are accessible from
The Modelica Association 311 Modelica 2006, September 4th – 5th D. Broman, P. Fritzson, S. Furic outside the instance. However, note that this is Let us now take a closer look at the grammar not the same as that variable x does not exist in listed in Figure 7. The root non-terminal of the a instance of B; it only means that it is not visible grammar is type, which can form a class or ob- to the outside world. ject type of the restricted classes or the built in Now, the following basic distinctions can be types Real, Integer, Boolean, String, or made between class types and object types: enumeration. The grammar is given using a variant of Extended Backus-Naur Form (EBNF), Classes can inherit (using extends) from class where terms enclosed in brackets {} denote zero, types, i.e., the type that is bound to the name one or more repetitions. Keywords appearing in used in an extends clause must be a class the concrete syntax are given in bold font. All type and not an object type. pre xes, such as public, flow, outer etc. can be given in nitely many times. The correct usage Class types can contain both object types and of these pre xes is not enforced by the grammar, class types, but object types can only hold and must therefore be handled later in the seman- other object types. tic analysis. We will give guidelines for default pre xes and restrictions of the usage of pre xes in Class types can contain types of protected el- the next subsection. ements; object types cannot. Now, let us introduce another model A, which extends from model B: Class types are used for compile time evalua- model A tion, such as inheritance and redeclarations. extends B(s=4); C c1; equation c1.q = -10*der(x); type ::= (model | record | connector | end A; block function package | | ) The question is now what the type of model A kindo ftype is and if it is instantiated to an object, i.e., A a;, {{pre fix} type identi fier ;} end what is then the type of a? The following shows | (Real | Integer | Boolean | the type of model A. String) kindo ftype model classtype //Class type of A | enumeration kindo ftype public parameter Real objtype s; enumlist public connector classtype flow Real objtype p; kindo ftype ::= classtype | objtype nonflow Real objtype q; pre fix ::= access | causality | end C; f lowpre fix | modi fiability | public connector objtype variability | outerinner flow Real objtype p; nonflow Real objtype q; enumlist ::= ( identi fier {, identi fier} ) end c1; access ::= public | protected protected Real objtype x; causality ::= input | output | end inputoutput First of all, we see that the type of model A does f lowpre fix ::= flow | nonflow not include any extends keyword referring to the modi fiability ::= replaceable | modifiable | inherited model B. Since Modelica has a structural final type system, it is the structure that is interesting, variability ::= constant | parameter | and thus a type only contains the collapsed struc- discrete | continuous ture of inherited elements. Furthermore, we can outerinner ::= outer | inner | see that the protected elements from B are still notouterinner available, i.e., inheritance preserves the protected element after inheritance. Moreover, since model A contains an instance of connector C, this is now Figure 7: Concrete syntax of partial Modelica available as an object type for element c1 in the types. class type of A. Finally, consider the type of an
The Modelica Association 312 Modelica 2006, September 4th – 5th Types in the Modelica Language instance a of class A: M = model R = record model objtype //Object type of a C = connector parameter Real objtype s; B = block connector objtype F = function flow Real objtype p; P = package nonflow Real objtype q; X = Integer, Boolean, end c1; enumeration, String end Y = Real The protected element is now gone, along with a = {public, protected} Access 0 the elements representing class types. A careful a = {public} c = {input, output, Causality reader might have noticed that each type de ni- inputoutput} tion ends without a semi-colon, but elements de- c0 = {input, output} ned inside a type such as model classtype f = {flow, nonflow} Flowpre x ends with a semi-colon. A closer look at the gram- m = {replaceable, Modi ability mar should make it clear that types themselves modifiable, final} do not have names, but when part of an element m0= {modifiable, final} de nition, the type is followed by a name and a v = {constant, parameter Variability discrete continuous semi-colon. If type expressions were to be ended , } v0 = {constant, parameter with a semi-colon, this recursive form of de ning discrete} concrete types would not be possible. v00 = {constant} o = {outer, inner, Outerinner 4.2 Pre xes in Types notouterinner} Elements of a Modelica class can be pre xed with Figure 8: Abbreviation for describing allowed pre- di erent notations, such as public, outer or xes. Default pre xes are underlined. replaceable. We do not intend to describe the semantics of these pre xes here, instead we refer Mc Rc Cc Bc Fc Pc Xc Yc to the speci cation [11] and to the more accessible Mc amo amo amo amo amo . amo amo R ...... description in [5]. Most of the languages pre xes c Cc ...... have been introduced in the grammar in Figure 7. Bc amo amo amo amo amo . amo amo However, not all pre xes are allowed or have any Fc . am . . am . am am 00 0 semantic meaning in all contexts. Pc am amv am am am a m am am In this subsection, we present a partial de ni- tion of when di erent pre xes are allowed to ap- Figure 9: Pre xes allowed for elements of class pear in a type. In currently available tools for type (columns) inside a class type (rows). Modelica, such as Dymola [4] and OpenModelica Mo Ro Co Bo Fo Po Xo Yo [6], the enforcement of these restrictions is sparse. 0 Mc amo acmo acmo amo amo . acmv o acmvo The reason for this can both be the di culties 0 Rc . mo . . . . mv o mvo to extract this information from the speci cation Cc . mo mo . . . m mc f vo 0 0 0 0 0 and the fact that the rules for the type pre xes Bc amo ac mo ac mo amo amo . ac mv o ac mvo 0 0 0 0 are very complex. Fc . ac m . . am . ac mv ac mv 00 00 00 In Figure 8 several abbreviations are listed. The Pc . amv . . . . amv amv lower case abbreviations a, c, c0 etc. de ne sets of Figure 10: Pre xes allowed for elements of object pre xes. The uppercase abbreviations M, R etc. type (columns) inside a class type (rows). together with a subscription of c for class type and o for object type, represents the type of an element part of another type. For example Mc is type that contains this element) states the al- a model class type, and Ro is a record object type. lowed pre xes for this particular element. This Now, consider the rules for allowed pre xes of table shows which pre xes that are allowed for elements shown in the tables given in Figure 9, a class type that is part of another class type. Figure 10, and Figure 11. For example, recall the connector C in model A. In Figure 9 the intersection between the col- When looking at the type of A, we have a class umn (the type of an element) and the row (the type (the model class type) that contains an-
The Modelica Association 313 Modelica 2006, September 4th – 5th D. Broman, P. Fritzson, S. Furic
Mo Ro Co Bo Fo Po Xo Yo ation or inheritance, i.e., compile-time evaluation. 0 0 0 0 Mo o cm o co o o . cm v o cm vo 0 0 0 0 Then when an object exists, the type information Ro . m o . . . . m v o m vo 0 0 for replaceable is of no interest any more. Finally, Co . m o o . . . . c f m vo 0 0 0 0 0 0 0 we can see that package class types can hold any Bo o c o c o o o . c m v o c m vo 0 0 0 0 other class types, but no other class type can hold Fo . c . . . . m v m v Po ...... package types. Note that several aspects described here are our Figure 11: Pre xes allowed for elements of object design suggestions for simplifying and making the type (columns) inside an object type (rows). language more stringent from a type perspective. Currently, there are no limitations for any class other class type (the connector class type), i.e., to contain packages in the Modelica speci cation. the allowed pre xes are given in the intersec- Furthermore, there are no strict distinctions be- tion of row 1 and column 3. In this case, ac- tween object- and class types, since elaboration cess pre xes public and protected, modi a- and type checking are not clearly distinguished. bility pre xes replaceable, modifiable, and Hence, redeclaration of elements in an object are final, and outer/inner pre xes outer, inner in fact possible according to the current speci ca- and notouterinner are allowed. tion, even if it does not make sense in a class based We have introduced a number of new pre xes: type perspective. inputoutput, notouterinner, nonflow, modifiable, and continuous. These new pre- xes are introduced to enable a complete type de- nition, e.g., it should be possible to explicitly 4.3 Completeness of the Type Syntax specify that a variable in a connector is not a ow variable by giving a nonflow pre x. However, One might ask if this type de nition is complete for simplicity, sometimes it is more convenient to and includes all aspects of the Modelica language leave out some of the pre xes, and instead use and the answer to that question is no. There are default pre xes. The de ned default pre xes are several aspects, such as arrays, partial and en- show underlined in Figure 8. If no underlined pre- capsulated classes, units, constrained types, con- x exists in a speci c set, this implies that the ditional components and external functions that pre x must be explicitly stated. are left out on purpose. Analogous to the description of Figure 9, Fig- The main reason for this work is to pinpoint the ure 10 shows the allowed pre xes for elements of main structure of types in Modelica, not to formu- object types contained in a class type and Fig- late a complete type de nition. As we can see from ure 11 shows object types contained in object the previous sections, the type concept in the lan- types. There are no tables given for class types guage is very complex and hard to de ne, due to contained in object types for the simple reason the large number of exceptions and the informal that object types are not allowed to contain class description of the semantics and type system in types. the language speci cation. In some of the cells in the tables described above, a dot symbol is shown. This means that The completeness and correctness of the allowed the speci c type of element inside a certain type type pre xes described in the previous section de- is not allowed. Hence, such a combination should pend on how the speci cation is interpreted. How- not be allowed by the compiler at compile-time. ever, the notation and structure of the concrete Now, let us observe some general trends be- type syntax should be consistent and is intended tween the allowed attributes. First of all, object to form the basis for incorporating this improved types cannot contain class types, which is why type concept tighter into the language. there are only 3 tables. Secondly, access pre xes Finally, we would like to stress that de ning (public, protected) are only allowed in class types of a language should be done in parallel with types, which is why Figure 11 does not contain the de nition of precise semantic and type rules. any abbreviation a. Thirdly, the replaceable Since the latter information is currently not avail- pre x does not make sense in object types, since able, the precise type de nition is obviously not redeclarations may only occur during object cre- possible to validate.
The Modelica Association 314 Modelica 2006, September 4th – 5th Types in the Modelica Language
5 Conclusion References
[1] Mart n Abadi and Luca Cardelli. A Theory of We have in this paper given a brief overview of Objects. Springer-Verlag, New York, USA, 1996. the concept of types and how they relate to the [2] Luca Cardelli. Type Systems. In The Computer Modelica language. The rst part of the paper Science and Engineering Handbook, chapter 97. described types in general, and the latter sections CRC Press, second edition, 2004. detailed a syntax de nition of how types can be [3] Luca Cardelli and Peter Wegner. On Understand- expressed for the Modelica language. ing Types, Data Abstraction, and Polymorphism. The current Modelica speci cation uses Ex- ACM Comput. Surv., 17(4):471–523, 1985. tended Backus-Naur Form (EBNF) for specify- [4] Dynasim. Dymola - Dynamic Modeling Labo- ing the syntax, but the semantics and the type ratory with Modelica (Dynasim AB). http:// system are informally described. Moreover, the www.dynasim.se/ [Last accessed: 8 May 2006]. Modelica language has become di cult to reason [5] Peter Fritzson. Principles of Object-Oriented about, since it has grown to be fairly large and Modeling and Simulation with Modelica 2.1. Wiley-IEEE Press, New York, USA, 2004. complex. By giving the types for part of the lan- guage we have illustrated that the type concept [6] Peter Fritzson, Peter Aronsson, H akan Lundvall, is complex in the Modelica language, and that it Kaj Nystr om, Adrian Pop, Levon Saldamli, and David Broman. The OpenModelica Modeling, is non-trivial to extract this information from the Simulation, and Development Environment. In language speci cation. Proceedings of the 46th Conference on Simulation Consequently, we think that it is important to and Modeling (SIMS’05), pages 83–90, 2005. augment the language speci cation by using more [7] Atsushi Igarashi, Benjamin C. Pierce, and Philip formal techniques to describe the semantics and Wadler. Featherweight Java: a minimal core cal- the type system. We therefore propose that a sub- culus for Java and GJ. ACM Trans. Program. set of Modelica should be de ned, which models Lang. Syst., 23(3):396–450, 2001. the core concepts of the language. This subset [8] David K agedal and Peter Fritzson. Generating a should be describe using operational semantics in- Modelica Compiler from Natural Semantics Speci- cluding formal type rules. For some time, deno- cations. In Proceedings of the Summer Computer Simulation Conference, 1998. tational semantics has been used as the semantic language of choice, however it has been shown to [9] Robin Milner. A Theory of Type Polymorphism in be less cumbersome to prove type soundness using Programming. Journal of Computer and System Sciences, 17(3):348–375, 1978. operational semantics [15]. [10] John C. Mitchell and Krzysztof Apt. Concepts in In the short term, this proposed core language Programming Languages. Cambridge University is supposed to be used as basic data for better Press, 2003. design decision-making, not as an alternative or [11] Modelica Association. Modelica - A Uni ed replacement of the o cial Modelica speci cation. Object-Oriented Language for Physical Systems However, the long term goal should, in our op- Modeling - Language Speci cation Version 2.2, tion, be to describe the entire Modelica language February 2005. Available from: http://www. formally. modelica.org [Last accessed: 29 March 2006]. [12] Benjamin C. Pierce. Types and Programming Lan- guages. The MIT Press, 2002. [13] Alan Snyder. Encapsulation and Inheritance in Acknowledgments Object-Oriented Programming Languages. In OOPLSA ’86: Conference proceedings on Object- oriented programming systems, languages and ap- Thanks to Thomas Sch on and Kaj Nystr om for plications, pages 38–45, New York, USA, 1986. many useful comments of this paper. ACM Press. [14] Don Syme. Proving Java Type Soundness. Lecture This research work was funded by CUGS (the Notes in Computer Science, 1523:83, 1999. Swedish National Graduate School in Computer Science), by SSF under the VISIMOD project, and [15] Andrew K. Wright and Matthias Felleisen. A Syn- tactic Approach to Type Soundness. Information by Vinnova under the NETPROG Safe and Secure and Computation, 115(1):38–94, 1994. Modeling and Simulation on the GRID project.
The Modelica Association 315 Modelica 2006, September 4th – 5th