ModIM - A Modelica Frontend With Static Analysis Christoph Höger Technische Universität Berlin (email: christoph.hoeger@tu-berlin.de ) Abstract: We present ModIM, a Modelica front-end library written in Java. ModIM is designed to not only support the development of Compilers/Interpreters but also tools that are currently underrepresented in the Modelica ecosystem. This includes (but is not limited to) advanced editors, documentation generators and model checkers. For that purpose ModIM offers a static environment generation and type inference algorithm. Both algorithms are adaptions of standard techniques to the characteristics of Modelica. Environment generation is rather complex, but specified intensely. The type system is straight forward, but lacks a formal specification and thus is an interpretation of the Modelica specifications intents. Additionally it is extended to also cover some unique features of Modelica. This extension consists of a formalization of the four kinds of variabilities and the introduction of a new type for unknowns. Keywords: Modelica, Abstract Syntax, Frontend, Java, Library, Static Analysis 1. INTRODUCTION Modelica (mod, 2010) is a modeling language for physical systems. The need for complementary tools and software grows, as the language becomes more and more successful in research as well as industrial application. Usually such software does not implement the complete model-compilesimulate workflow (which is already covered quite well). Instead, it focuses on a single task in or next to this workflow (e.g. version control (Harman, 2011)). Since Modelica is currently usually interpreted just prior to the generation of simulation code, there is little to no available support for the development of such tools. Especially there is currently no library that one could use for static analysis of Modelica models. model example Real x,y; discrete Boolean b(start = false); equation when time > 1 then b = true; end when; x = time; y = if b then y else x; end example; Listing 1. Modeling error Listing 1 motivates the need for such static analysis. It contains an equation which is obviously singular (for time > 1). This kind of error appears at simulation time and is only reported as a simulation failure in current tools. Usually the model s author is not the same person as its end user (the one who actually does a simulation). A developer thus has no means to ship a model which is checked to be free from such errors. A static analysis of the partial model (before distribution) can prevent those cases. In this paper we present ModIM ( Modelica Intermediate Model ), a Java library which is designed for static analysis of Modelica models. ModIM contains a complete abstract syntax for Modelica, a lexer/parser implementation and a static type checker. The rest of the paper is organized as follows: First, we will present the design (and reasons for the design-decisions) behind ModIM. Second, we will give a short overview of how to use it. Afterwards we will present the formal concepts behind the type checker that is implemented in ModIM. Finally, the paper will close with an outlook to future development. 2. LIBRARY DESIGN The design of ModIM is lead by several decisions. We will discuss the most significant of them. The implementation of ModIM in Java is the first important design choice. This has little to do with Java s superiority over any other language (assuming such an advantage would even exist), but with some pragmatic thoughts: First of all, Java (and thus ModIM) is platform independent free software. Second, Java is broadly adopted in industry and science. And last but not least Java provides a healthy ecosystem of libraries, build systems etc. which simplifies the development process of ModIM itself. The second design decision for ModIM is the absence of Object orientation. More precisely: ModIM is not designed for extensibility. In an object-oriented design, functions (or methods) are tightly coupled with data structures (or objects). This design allows to extend a library with a new data structure by simply implementing all those (abstract)
methods once for the new object. On the same time this makes it notoriously hard to implement a new function for all data structures. Especially it makes it impossible to implement two new functions independently in parallel (since both would need to change every object definition). Because these limitations would affect the usability of ModIM as a front-end library, we decided that the data structures should be fixed. Operations on those data structures are implemented following the visitor-pattern (Gamma et al., 1994). Thus the implementation of a new operation is straight-forward (in turn, the addition of a new data structure becomes rather complex). This decision was also supported by the fact that Modelica itself is fixed by its specification. Thus a new data structure should only be necessary for a new language version. The next design decision is concerned with the content of ModIM s data structures: The core of ModIM is a typeannotated abstract syntax tree. Persistently annotating the tree with its types instead of throwing away that information distinguishes ModIM from a usual compiler front-end. It becomes comfortable to develop tools like editors, documentation generators and so on(while writing a compiler or interpreter is still possible). Currently ModIM does not allow for further generic attributes. This limitation is not fixed but was introduced for pragmatic reasons (generic attributes would require an implementation that has some performance penalty. With types being the only attributes for now that penalty seemed unreasonable.). Finally, the most important design decision (and the very reason for ModIM s existence) is the equal treatment of any possible use case. ModIM as a general purpose library does not make any assumption about how it should be used. It may be used in an interpreter, compiler, embedded in an integrated development environment or wherever it seems useful. 3. LIBRARY USAGE The data structures in ModIM are separated from the algorithms, as already discussed above. A third part of the library is concerned with the input processing: This module handles the lexing, parsing and abstract syntax generation. The parser is currently generated with ANTLR, but other implementations are possible (older versions of ModIM used PaGe, an experimental incremental LALR parser generator (Höger, 2009)). Naturally, ModIM is implemented on top of several other libraries. All those dependencies are (as ModIM) free software and thus provide no additional barriers for users of the library. (Technically the dependency management is handled by ModIM s build system of choice, maven.) public static void main(string[] args) { final List<String> arglist = Arrays.asList(args); final TypeChecker typechecker = new TypeChecker( LOAD_AST, arglist.sublist(1, arglist.size())); } final IStoredDefinitionNode root = LOAD_AST.apply(new File(args[0])); /* apply type check */ root.accept(typechecker); /* report type errors */ for (Entry err : typechecker. gettypeerrors(). entryset()) { report(err.getkey(), err.getvalue()); } Listing 2. ModIM example Listing 2 shows how a simple static analysis tool might be implemented by using ModIM: Given a LOAD AST delegate, which invokes the parser from the input module, and the type-checker, a tool can load and check any Modelica source files and report all type errors it encountered. Even though the listing does not show any elaborate algorithm, it demonstrates two important aspects of ModIM clients: The input source is exchangeable. In general, a good client should not depend on any particular parsing method, since it might be used in a different context. The algorithms (the type-checker in this case) are implemented as visitors and can be invoked on any data structure. To do so, the data structure (in our case the StoredDefinitionNode) is asked to accept the visitor. It is important to note that ModIM s data structures are twofold: On the one side there is the abstract syntax. This data structure is kept as close as possible to the specified Modelica grammar. This part of the library is unlikely to change and should be relatively easy to understand for tool developers. On the other side there is the type system. Modelica does not contain an abstract definition of its types. Therefore all data-structures here are interpretations of the specification. Furthermore, the type system itself is subject to ongoing research. The design and intentions of this part of the library will be discussed below. 4. TYPE CHECK When studying the type system of Modelica it becomes apparent that there is actually no definition of type-safety in the specification. This is of course due to the lack of a well-defined evaluation strategy for expressions. For any formal type system this means, that correctness cannot be proved. So instead of aiming at correctness, our focus in this paper lies more on a type system as means of communication. In the following we will write type system rules as inference rules: Γ e 1 : R e 2 : R Γ e 1 + e 2 : R In such a rule Γ, as usual, describes a type environment, containing declarations. e i describes an expression of the language, which (due to the size of the Modelica grammar)
will not further be specified in this paper. Concrete syntax elements are written in fixed size font. A statement Γ e : τ reads: Under the type environment Γ, e has type τ. If all premises of the rule are fulfilled, the conclusion also holds. Although we do not aim at full formalization or type safety proofs, partially formalizing the type system in such a way serves a purpose: The type checker in ModIM is implemented as an inference engine that applies such a rule to every expression. Therefore inference rules are a concise way to describe the algorithm. 4.1 Types Types in Modelica have been subject to research (Broman et al., 2006) from a model composition perspective. In contrast, ModIM s type-checker aims at the expression level. Consequently in the abstract syntax tree the only elements that can be annotated with a type are expressions. As most languages, Modelica contains of a finite set of built-in types and several type expressions that allow users to define their own types. The built-in types of Modelica are Boolean, Real, String and Integer. We write those types as B = {S,R,I,B}. The user-derived types are given by the following grammar: UserType ::= Rec Arr Tup Fun Inst Rec ::= { (Name :T)+ } Tup ::= (T+ ) Arr ::= T [Expr+ ] Fun ::= T T Inst ::= Name This grammar contains the complex types a user can create: records, (multi-dimensional) arrays, functions (we left out named- and default-parameters here for brevity) and model instances (only a reference to a model in ModIM). Tuples are not explicitly mentioned in the specification but implicitly contained, since Modelica allows for functions with multiple return values (even if only in a syntactically restricted way). The grammar shows that Modelica s type system does not contain parametric polymorphism in expressions, since there are no type variables a user could define. Though the influence of redeclarations (see below) on function definitions still needs to be evaluated. Variability Abbrev. can change constant c never parameter p at simulation start discrete d during events continuous t with every time step Fig. 1. Variabilities in Modelica In contrast to most declarative programming languages, Modelica describes time-variant systems. This means that expressions may evaluate to different values at different points in time. This fact is well known from most imperative languages, where basic types are annotated with an additional flag (often called the constness), which indicates, weather they might change or not. Modelica contains four such kinds of variability (Figure 1). WecallthesetofvariabilitiesV = {c,p,d,t}andintroduce an ordering c < p < d < t. Now we can provide the concrete syntax of types as they are implemented by ModIM: Type ::= <V T > T ::= B UserType type T var Type Here the set T describes, what we will call simple types. Simple types are extended with a variability to form a type. The elements after user-defined and built-in types need some explanation: The first one, type T is simply a concession to a more technical problem: ModIM s type inference is implemented as a visitor and annotates every expression with its type. This means, that the names of classes, functions etc. also need to have a type. The solution chosen is to give them a second-order type. Although Modelica does not actually require higher-order types, this allows to use simpler datastructures and even to define some type rules in a simpler way (e.g. the direct access of constant elements from class names). The second addition is a little bit more complicated: The semantic domain of Modelica is a system of differential and algebraic equations. Such a system naturally contains unknowns,whichneedtobesolvedatagivenpointintime. Although syntactically similar to parameters and constants, those unknowns are semantically different: They can only be evaluated at simulation time. Operationally, they behave much more like functions (ranging over time), than numerical values. Before we can show why this second addition was necessary, we need to introduce some relations over the now complete set of types. First of all, we introduce the common subtype relation between simple types: T T We are not going into details on the topic of subtyping, since for all elements of T well known subtyping rules exist (see e.g. Pierce (2002) for a detailed discussion of the topic). Those rules are based on the substitution principle, meaning that any subtype can safely be used instead of a supertype at any place. We will give just one example for the classical subtyping rule on functions: γ α β δ α β γ δ This rule shows how the substitution principle leads to a contravariant relationship between the arguments of two functions. Likewise we can define on records, tuples etc. Subtyping on arrays was chosen to be covariant in ModIM (since Modelica does not contain typecasts, write access to an array does not change the type of the stored content).
As usual, is a reflexive, transitive and antisymmetric relation. So by adding and to T as least and greatest elements, becomes a lattice. Since we have already introduced an ordering < on the variabilities (and thus ), we can lift the subtype relation of simple types to a subtype relation on types: <: Type Type t 1 t 2 v 1 v 2 v 1,t 1 <: v 2,t 2 It is easy to see that <: also is a lattice with c, and t, being the least and greatest elements. This allows us to use the supremum and infimum in our type rules. 4.2 The Variable Type As already mentioned, unknowns can only be evaluated at simulation time. One could argue that, because the same property holds for every expression with continuous variability, such an extension is redundant from a evaluation perspective. Yet, from the static analysis perspective, this does not suffice. Consider a generic rule for if-expressions: Γ e 1 : v 1,B Γ e 2 : τ 1 Γ e 3 : τ 2 v 2,t = τ 1 τ 2 t Γ if e 1 then e 2 else e 3 : max(v 1,v 2 ),t This rule defines, that an if-expression yields the least common supertype of the then- and the else-branch. There is nothing wrong with that kind of type judgments, when it comes to expression evaluation. Indeed, when computing i.e. the residual, this is exactly the kind of type check that prevents us from adding strings to real-values, but allows to mix integers with floating point numbers. Yet, without the variable type one important piece of information is lost: In the example model in listing 1, the if- expression would have the type t,r (i.e. it is a continuous-time expression yielding real values). Yet in fact it yields different unknowns depending on the value of the discrete-time variable b. Thus, the system is structurally dynamic (see, e.g. Zimmer (2010) for a detailed discussion of this topic), as can be seen with the variable type: Γ b : d,b Γ x : c,var t,r Γ y : c,var t,r Γ if b then y else x : d,var t,r As mentioned earlier, ModIM is agnostic over its clients. While some tool might be able to handle such dynamics (or even not be interested in it at all), others might rely on this information. Therefore ModIM will annotate such expressions accordingly. As a side effect, several built-in operators (e.g. reinit()), or the left-hand-sides of whenequations can now be checked easily. To allow the evaluation of unknowns at simulation time, we simply need to add a special subtyping rule: v 3 = max(v 1,v 2 ) v 1,var v 2,t <: v 3,t This basically means that an unknown can always be evaluated and yields a value which has at least the variability of the unknown s content. Additionally, if a model contains records for the declaration of unknowns, a special lookup rule is applied(a similar rule exists for array-access of variables): Γ e : v 1,var v 2,t 1 t 1 {x : t 2 } Γ e.x : v 1,var v 2,t 2 4.3 Environment Creation The extension of the type-environment is usually defined alongside with the type rules. In academic languages, where the only source for environment extension consists of function abstraction or let-expressions, this might suffice. For ModIM, we will discuss the environment separately from the type analysis for several reasons: First, Modelica has no formally defined type system. Instead several rules are given in plain English in the specification. Here we see a clear distinction between types for expressions and objects (which are due to the structural kind of Modelica s type system defined by the lookup rules). Thus by creating the environment by a separate algorithm our implementation stays closer to the specification in at least an organizational sense. Second, ModIM is, as already mentioned, not designed to support only the usual check and forget design of interpreters and compilers. Instead, we want to allow for interactive work with the abstract syntax tree. This is much easier when the type environment can be created on demand for a certain tree-node. Thus the environment becomes an annotation of a given tree (Currently this annotation needs to be stored separately, because there is yet no generic attribute mechanism in ModIM. But this is just a technical issue.). Finally, the distinction between lookup and type errors allows better error messages: Some type errors tend to be rather large and hard to read. (e.g. the fact that the least common supertype of several else-if expressions is is relatively hard to understand.) On the other hand, name errors (like double definition) are rather easy to report. As usual Modelica s type environment consists of element declarations in the form x :Type. The basic lookup is specified by a simple type rule: Γ(x) = τ Γ x : τ While this a standard technique, the actual implementation of Γ and its calculation is far more interesting. In Modelica, several sources contribute to the type environment of a class. These are: The lexical scope. As most languages, Modelica supports the access to names upwards the abstract syntax tree. Thus, the environment of the parent node is
the originofaclass ownenvironment.notallofthem can be accessed legally (e.g. unknowns), but this is a technical detail. The external environment. This source contains elements that are defined outside of the current compilation unit. It is only technically different from the lexical scope. Local type declarations. If a class contains another class, it can be accessed by its name. Thus the first component of the local environment is the set of local classes, functions, etc. Imports. Modelica allows to import other classes (or their components) into the current scope. Inherited environments. All components of every super-class are part of the sub-class environment. Again, not all of the elements are legally accessible (e.g. protected elements). Local components. Naturally, the locally defined components are part of the local environment. With the exception of the lexical scope, all of those sources are disjoint (i.e. they do not yield the same name twice, otherwise this is an error). So for the lookup it does not matter in which order they are processed. The lexical scope needs to be the last source of a name, since shadowing of names is allowed. Mathematically, lookup is a partial function from names to types: Γ : Name Type. This function can easily be implemented as a map. In ModIM we choose to use a list of maps, since we wanted to reduce the overhead of e.g. copying a class local environment into the inherited environments of another class. protected final LinkedList<Map<String, Type>> getidentifiermap(final IClassNode node) { final ClassScope scope = ccm.getscopefor(node); final LinkedList<Map<String, Type>> completescope = Lists. newlinkedlist(); final Map<String, Type> externalsmap = getexternalenvironment( node, scope); completescope. add( externalsmap); lookup.add(externalsmap); final Map<String, Type> localtypesmap = getlocaltypeenvironment( node, scope); lookup. add( localtypesmap); completescope. add( localtypesmap); final LinkedList<Map<String, Type>> importmap = createimports( node, scope); lookup.addall(importmap); completescope. addall( importmap); final List<Map<String, Type>> extmap = getextensionenvironment( node, scope); lookup.addall(extmap); completescope. addall( extmap); handleshortextends( node, scope); final Map<String, Type> childmap = } getcomponentenvironment( node, scope); completescope. add( childmap); lookup.add(childmap); scope. completescope = completescope; return scope. completescope; Listing 3. Generating the environment Listing 3 shows the key method in static lookup (stripped from caching, error detection etc. for brevity): The method getidentifiermap() returns the union of a class environment sources, implemented as a linked list of partial environment maps. This list contains all (including protected members and types) identifiers that are valid in the scope of the given class. While doing so, a the locally used environment lookup is extended. The already mentioned lookup function is implemented by searching through all maps in the list in reverse order. This guarantees lexical shadowing of names. The order, in which the type environment is created, is important: While the order of lookup does not matter for the disjoint sources, the order of creation does. An importstatement, for instance, contains a name on its left-handside. This name needs to be looked up (i.e. searched in the local environment). It may (according to the language specification) not depend on local or inherited, but on external or surrounding declarations so those must already exist in the environment. The same kind of dependencies can be applied to extendstatements and local components. Thus the side effect of extending the environment (the lookup.add(...) invocations) needs to be applied exactly in the given order. 4.4 Type Rules As already mentioned, the system of simple types in Modelica is, well, simple. Yet we will present two interesting rules as they are implemented in ModIM: First, consider the rather important derivative operator der() in Modelica. Obviously, if applied to a variable of the continuous type, the result is again a continuous real expression (one might even argue, if the result shall be a variable again). This is implemented by the following rule: Γ e :,var t,r Γ der(e) : t,r But what about parameters and constants? The specification states: For Real parameters and constants the result is a zero scalar or array of the same size as the variable. Thus, the value of the operator is known at compile time (0) and the resulting type is a constant: Γ e : v,r v < d Γ der(e) : c,i The other interesting rule is concerned with the delay() operator. The specification demands:
The arguments, i.e., expr, delaytime and delaymax, need to be subtypes of Real. Delay- Max needs to be additionally a parameter expression. [...] If delaymax is not supplied in the argument list, delaytime need to be a parameter expression. The corresponding rules could be implemented as: Γ e 1 : τ 1 Γ e 2 : τ 2 Γ e 3 : τ 3 τ 1 <: v,r τ 2 <:,R τ 3 <: p,r Γ delay(e 1,e 2,e 3 ) : τ 1 Γ e 1 : τ 1 τ 1 <: v,r Γ e 2 : τ 2 τ 2 <: p,r Γ delay(e 1,e 2 ) : τ 1 5. FUTURE WORK ModIM currently supports large parts of the Modelica Standard Library (version 3.2). Out of 182 files, around 170 already pass the type-check. Most of the failing test cases are due to a currently missing implementation of function partial evaluation through Modelica s modifications. Yet some are failing simply because of bugs. Besides those obvious reasons, there are several other points of interest for future development: 5.1 Redeclarations Redeclarations are Modelica s way of bounded parametric polymorphism. By lexically introducing a component with a redeclare flag, a model author indicates that he or she wishes to use the locally defined type instead of the inherited type ofthe samename.this alsoappliestousage ofthe inherited type (soall complextypes that containthe redeclared type are changed as well). While ModIM currently already supports redeclarations, it does so in an inefficient manner. Currently, all types in all inherited environments are subject to the application of redeclarations. This is, of course, costly. A future version of ModIM might make usage of type-variables to make this search unnecessary. 5.2 Use Cases Development of what later should become ModIM originally started as a compiler front-end. This use-case largely influenced the need for static analysis and independence from the operational-style specification. Yet, since ModIM shall support any use-case equally, there is the need for some (demonstrating) clients. Current plans contain an interpreter(implementing flattening on top of ModIM) and a documentation generator. Future development might also see a semantic style-checker (like CheckStyle (Burn, 2001) or FindBugs (Hovemeyer and Pugh, 2004)). 5.3 Adding Relations Currently ModIM is only equipped with the relations it needs for static analysis. Further versions could be extended in that regard: With the implemented type-checker we can make type judgments for the problematic equation in Listing 1. Note that x itself is of constant type, since whenever we denote that expression it yields the same variable: Γ x : c,v[ t,r ] Now a compiler author might be interested in the question, which variables an expression can always yield a solution for. Therefore we can introduce the relation. This relation can easily use the existing type-annotations: Γ e : c,var τ Γ e {e} The author then just needs to implement the interesting cases: Γ e 1 V 1 Γ e 2 V 2 Γ if then e 1 else e 2 V 1 V 2 Such a relation can be easily implemented in ModIM with only very few lines of code. While this relation might not be general enough to find its way into the semanticsof Modelica, it is still useful and could be partof some (automatically checked) style guide. Unfortunately, the author must currently develop an implementation for every syntactic element (of which Modelica contains a large amount). ModIM should support the implementation of default rules and combinators for such relations. With that infrastructure, an author could develop, document and combine new relations easily. REFERENCES (2010). Modelica - a unified object-oriented language for physical systems modeling. URL http://www. modelica.org/documents/modelicaspec32.pdf. Broman, D., Fritzson, P., and Furic, S. (2006). Types in the Modelica Language. In Proceedings of the Fifth International Modelica Conference. Vienna, Austria. Burn, O. (2001). Checkstyle. Computer Program. URL http://checkstyle.sourceforge.net/. Gamma, E., Helm, R., and Johnson, R.E. (1994). Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley Longman, Amsterdam, 1st ed., reprint. edition. Harman, P. (2011). Effective version control of modelica models. In Proceedings of the 8th International Modelica Conference, March 20th-22nd, Technical Univeristy, Dresden, Germany, Linköping Electronic Conference Proceedings, 650 656. Linköping University Electronic Press, Linköpings universitet. Höger, C. (2009). Generation of incremental parsers for modern ides. In J. Knoop and A. Prantl (eds.), KPS 09: 15. Kolloquium Programmiersprachen und Grandlagen der Programmierung. Hovemeyer, D. and Pugh, W. (2004). Finding bugs is easy. In ACM SIGPLAN Notices, 132 136. ACM Press. Pierce, B.C. (2002). Types and Programming Languages. MIT Press. Zimmer, D. (2010). Equation-based Modeling of Variablestructure Systems. Ph.D. thesis, ETH Zürich.