Change 'Flat Modelica' -> 'Base Modelica' in most places

Some documents, for example old meeting minutes, are not touched.

RationaleMCP/0031/Flat-Modelica-requirements.md

@@ -1,9 +1,9 @@
-# Requirements on Flat Modelica
-This document should contain a first draft of the requirements on what Flat Modelica should and shouldn't be, to be used as a starting point for discussions at the upcoming design meeting in Regensburg on March 7-8, 2019.  It also contains a rough separation of things belonging to the three main parts of the Modelica Language Specification (MLS) that would come out of this MCP.
+# Requirements on Base Modelica
+This document should contain a first draft of the requirements on what Base Modelica should and shouldn't be, to be used as a starting point for discussions at the upcoming design meeting in Regensburg on March 7-8, 2019.  It also contains a rough separation of things belonging to the three main parts of the Modelica Language Specification (MLS) that would come out of this MCP.
 
-## Flat Modelica features
+## Base Modelica features
 
-Things that the Flat Modelica format should support:
+Things that the Base Modelica format should support:
 - Basic scalar types with the same attributes as in Modelica.
 - Record and enumeration types.
 - Arrays.
@@ -20,7 +20,7 @@ Things that the Flat Modelica format should support:
 - Vendor-specific annotations.
   - Comment (@mtiller): So annotations are present in the grammar but all annotations except vendor annotations are stripped.  If the concern is bloat from annotations that are no longer relevant in the flattened form (*e.g.,* graphical annotations), why not identify what gets excluded vs. what gets included? (see comment about source locations above)
   - Comment (@harmanpa): I agree, I'd like to be able to put arbitary meta-data in.
-- All variabilities, but constant evaluation of parameters is not allowed.  (For example, this guarantees that all parameters will remain parameters if a Flat Modelica model is exported to an FMU for Model Exchange.)
+- All variabilities, but constant evaluation of parameters is not allowed.  (For example, this guarantees that all parameters will remain parameters if a Base Modelica model is exported to an FMU for Model Exchange.)
   - Comment (@mtiller): The semantics of this are unclear.  When you say constant evaluation, do you mean constant folding?  What about `final` parameters?  Should those be parameters in an FMU? I wouldn't think so.  It seems like they should just be `output`s.
 - List of all `parameter` variables that were treated as `constant` due to use in _parameter expressions_, the `Evaluate=true` annotation, or subject to constant evaluation during flattening for other reasons.
   - `final` can probably be replaced by using normal equation instead of binding equation. meaning that binding eqations can always be treated as non-final.
@@ -37,7 +37,7 @@ Things that the Flat Modelica format should support:
   - Comment (@mtiller): Do we flatten the functions?  I say that because functions can use features like `extends` or `redeclare` in their definitions.  Presumably we want all that removed in a flattened form, no?  Functions should probably be allowed to have arguments of array and record type.
   - Comment (@harmanpa): Yes. Additionally we might have multiple versions of functions, because we might call a function with different dimension inputs. We need a naming convention for this.
 
-Examples of things that should be gone after flattening and shouldn't exist in Flat Modelica:
+Examples of things that should be gone after flattening and shouldn't exist in Base Modelica:
 - Complex classes that may contain equations.
 - Connectors.
 - Conditional components.
@@ -63,11 +63,11 @@ Content of that should go into this section:
 - Expressions.
 - External functions.
 - User-defined functions.
-- Restricted forms of record field access and array subscripting (some or all of the restrictions may be lifted for Flat Modelica).
+- Restricted forms of record field access and array subscripting (some or all of the restrictions may be lifted for Base Modelica).
 - Unit expressions.
 - Syntax for synchronous language elements and state machines.
 
-### Flat Modelica
+### Base Modelica
 Content of that should go into this section:
 - Overview of execution model for hybrid differential-algebraic equations.
 - Simulation initialization and priority of non-fixed start attributes.

RationaleMCP/0031/ReadMe.md

@@ -1,16 +1,16 @@
-# Modelica Change Proposal MCP-0031<br/>Flat Modelica and MLS modularization
+# Modelica Change Proposal MCP-0031<br/>Base Modelica and MLS modularization
 Peter Harman, Werther Kai, Gerd Kurzbach, Oliver Lenord, Hans Olsson, Michael Schellenberger, Martin Sjölund, Henrik Tidefelt
 
 **(In Development)**
 
 ## Summary
-This MCP is a new attempt at introducing a specification of an intermediate format which will be called _Flat Modelica_.
+This MCP is a new attempt at introducing a specification of an intermediate format which will be called _Base Modelica_.
 
 ### In a sentence (or two)
-Flat Modelica is a language to describe hybrid (continuous and discrete) systems with emphasis on defining the dynamic behavior.  It is an integral part of the Modelica specification, not a new separate standard.
+Base Modelica is a language to describe hybrid (continuous and discrete) systems with emphasis on defining the dynamic behavior.  It is an integral part of the Modelica specification, not a new separate standard.
 
 ### Use cases
-Use cases to have in mind in the design of Flat Modelica, also indicating the usefullness of the Flat Modelica endeavor:
+Use cases to have in mind in the design of Base Modelica, also indicating the usefullness of the Base Modelica endeavor:
 * Serve as intermediate stage in the Modelica specification, separating front end matters (the high level constructs of the Modelica language) from back end matters (simulation semantics).
   - Generally speaking, the two different matters will attract attention from people with quite different interests and areas of expertise (compuer science and numerical mathematics, respectively).
   - Separation will facilitate more efficient work and rapid development of the two aspects of the Modelica language.
@@ -28,21 +28,21 @@ Use cases to have in mind in the design of Flat Modelica, also indicating the us
 * IP protection when combined with obfuscation.
 
 ### Relation to eFMI
-One of the key use cases driving the development of Flat Modelica is its use as basis for the _Equation Code_ of [eFMI](https://itea3.org/index.php/project/emphysis.html).  The requirements for eFMI are much smaller in terms of language features compared to the needs for serving as intermediate representation in the Modelica standard.  To accommodate both use cases, the Equation Code of eFMI will be defined as a restricted variant of Flat Modelica.
+One of the key use cases driving the development of Base Modelica is its use as basis for the _Equation Code_ of [eFMI](https://itea3.org/index.php/project/emphysis.html).  The requirements for eFMI are much smaller in terms of language features compared to the needs for serving as intermediate representation in the Modelica standard.  To accommodate both use cases, the Equation Code of eFMI will be defined as a restricted variant of Base Modelica.
 
 ### Requirements
 From the use cases above, some implicit requirements follow:
 * Simple enough to be attractive for applications that essentially just want a simple description of variables and equations, meaning that many of the complicated high level constructs of Modelica are removed.
-* Expressive enough to allow the high level constructs of Modelica to be reduced to Flat Modelica without loss of semantics.
-* When Flat Modelica serves as an intermediate representation of the translation of a higher level language (such as Modelica), errors detected in Flat Modelica code shall be traceable to the original code.
-* Human readable and writeable, since not all use cases assume Flat Modelica being produced from a higher level language by a tool.
+* Expressive enough to allow the high level constructs of Modelica to be reduced to Base Modelica without loss of semantics.
+* When Base Modelica serves as an intermediate representation of the translation of a higher level language (such as Modelica), errors detected in Base Modelica code shall be traceable to the original code.
+* Human readable and writeable, since not all use cases assume Base Modelica being produced from a higher level language by a tool.
 
 ## Roadmap
 Due to the large size of this MCP, it has been necessary to break it down into smaller subtopics.  Some of these may will be complicated enough to require their own discussion threads (in the form of pull requeststs to the MCP branch), while other may be resolved more easily during meetings and be implemented directly on the MCP branch.
 
-### Flat Modelica 0.1 (this MCP)
-These are subtopics that are considered necessary to resolve for a first version of Flat Modelica.  By keeping this list short, increase chances of ever getting to the release of a first version.
-- [x] Flat Modelica identifier naming scheme.
+### Base Modelica 0.1 (this MCP)
+These are subtopics that are considered necessary to resolve for a first version of Base Modelica.  By keeping this list short, increase chances of ever getting to the release of a first version.
+- [x] Base Modelica identifier naming scheme.
 - [x] Principles for use of language constructs vs annotations.  [Design](annotations.md), [PR with discussion](https://github.com/modelica/ModelicaSpecification/pull/2459)
 - [x] Get rid of the obviously irrelevant parts of the grammar.  [Design](grammar.md), [PR with discussion](https://github.com/modelica/ModelicaSpecification/pull/2465)
 - [x] Get rid of `connect` equations.
@@ -73,10 +73,10 @@ These are subtopics that are considered necessary to resolve for a first version
 - [ ] Figure out what to do with synchronous features.
 - [ ] Event handling semantics is preserved as in Modelica.
 - [ ] Source locations pointing back to the original Modelica code.
-- [ ] Settle the name (currently _Flat Modelica_), considering that scalarization isn't mandatory.
+- [ ] Settle the name (currently _Base Modelica_), considering that scalarization isn't mandatory.
 
-### Flat Modelica 0.1+…1.0 (future MCPs)
-In future minor versions of Flat Modelica 1, we could improve the language by incorporating smaller improvements that were not considered necessary for version 1.0.
+### Base Modelica 0.1+…1.0 (future MCPs)
+In future minor versions of Base Modelica 1, we could improve the language by incorporating smaller improvements that were not considered necessary for version 1.0.
 - [ ] Handling of parameters treated as constants. [Previous discussion](https://github.com/modelica/ModelicaSpecification/pull/3161)
 - [ ] Primitive operations for triggering of events, to which the current event generating functions can be reduced.
 - [ ] Get rid of function calls with named arguments.
@@ -88,7 +88,7 @@ In future minor versions of Flat Modelica 1, we could improve the language by in
 - [ ] Reintroduce `each` for efficiency and to avoid code duplication.
 - [ ] Figure out what to do with Connectors and FMI3.0 Terminals.
 
-### Flat Modelica 2.0 (future MCPs)
+### Base Modelica 2.0 (future MCPs)
 Big changes that don't make sense to even consider for a minor release of version 1 are listed here.  Being listed here shall not be interpreted as even being likely to ever happen; this is just a collection of all the ideas that don't fit in the more realistic roadmap for version 1.
 - [ ] Allowing some simple form of `model` that makes it possible to preserve structure of the equations that will allow more efficient symbolic processing and production of executables of much smaller size.
 
@@ -101,13 +101,13 @@ Big changes that don't make sense to even consider for a minor release of versio
 All authors of this MCP or their organizations have signed the "Modelica Contributor License Agreement".
 
 ## Rationale
-The requirements on what Flat Modelica should and shoudn't be are currently being developed in a [separate document](Flat-Modelica-requirements.md).
+The requirements on what Base Modelica should and shoudn't be are currently being developed in a [separate document](Flat-Modelica-requirements.md).
 
 ## Backwards Compatibility
 It is the goal of this MCP that it should only change the way the Modelica language is described, not either adding, removing, or changing any of the Modelica language features.  Hence, it should be completely backwards compatible.
 
 ## Tool Implementation
-While existing Modelica implementations should work just as well before as after incorporation of this MCP, there should still be a proof of concept implementation showing how Flat Modelica can be produced by a tool, and that the Flat Modelica output can then be used as input to a Modelica back end for simulation.  Ideally, this should be demonstrated using different tools for the two tasks.
+While existing Modelica implementations should work just as well before as after incorporation of this MCP, there should still be a proof of concept implementation showing how Base Modelica can be produced by a tool, and that the Base Modelica output can then be used as input to a Modelica back end for simulation.  Ideally, this should be demonstrated using different tools for the two tasks.
 
 ### Experience with Prototype
 (None, so far.)

RationaleMCP/0031/annotations.md

@@ -7,21 +7,21 @@ This section describes the design question of when to use an annotation and when
 
 ### Design guidelines
 
-The following guideline shall be applied when determining whether to use an annotation to convey information in Flat Modelica:
-- Information kept in annotations in Modelica shall remain annotations in Flat Modelica.
+The following guideline shall be applied when determining whether to use an annotation to convey information in Base Modelica:
+- Information kept in annotations in Modelica shall remain annotations in Base Modelica.
 
-There are no design guidelines for how to convey information needed for Flat Modelica when there is no counterpart in Modelica.  Design decisions will be have to be made case by case.
+There are no design guidelines for how to convey information needed for Base Modelica when there is no counterpart in Modelica.  Design decisions will be have to be made case by case.
 
 ### Rationale
 
 With the flexible structure of annoations, it is possible to use annotations for anything that could also have been a first class attribute in the language.  These are the main arguments for and against the proposed guidelines versus a restriction not not use annotations for anything that may impact symbolic or numeric processing:
-- (+) Some Modelica users would be suprised to find out if something like `GenerateEvents = true` (which is an annotation in Modelica) wasn't an annotation in Flat Modelica.
+- (+) Some Modelica users would be suprised to find out if something like `GenerateEvents = true` (which is an annotation in Modelica) wasn't an annotation in Base Modelica.
 - (+) Disregarding annotations allows users non-Modelica background to not be put off by things such as `LateInline` that they don't have an intuition for.
 - (-) Seeing the annotations that impact the simulation result among all other information stored in annotations will require tool support beyond simply collapsing all annotations.
 - (-) The (overly) flexible structure of annoatations makes it harder to detect mistakes, whereas the exact syntax of primitive language constructs could have been expressed in the language grammar.
 
 
-## Summary of Flat Modelica annotations
+## Summary of Base Modelica annotations
 
 These are all the non-vendor specific annotations inherited from full Modelica that may influence the code generation process:
 - `Inline` — Applied to a function, indicates it should be inlined
@@ -36,7 +36,7 @@ These are all the non-vendor specific annotations inherited from full Modelica t
 - `HideResult` — Applied to a parameter or variable, implies the variable should not be included in the simulation output
 - `choices` — Applied to a parameter or variable, can be used to enumerate and tag different values for parameter input
 
-These are the new annotations introduced in Flat Modelica, each explained in more detail below:
+These are the new annotations introduced in Base Modelica, each explained in more detail below:
 - [`Protected`](#protected) — Indicate whether component declaration comes from protected section in original full Modelica model
 
 
@@ -54,10 +54,10 @@ The annotation does not come with any hard semantics, but can be useful for thin
 - guiding which variable name to keep when performing alias elimination
 - criterion for selection of which variables to include in the simulation result stored to file
 
-When the Flat Modelica is generated from a full Modelica model, a component coming from a protected section (except inside functions) in the full Modelica model shall have the annotation `Protected = true` in Flat Modelica.
+When the Base Modelica is generated from a full Modelica model, a component coming from a protected section (except inside functions) in the full Modelica model shall have the annotation `Protected = true` in Base Modelica.
 A component coming from a public section must not have the `Protected = true` annotation.
 
-When the Flat Modelica is not generated from a full Modelica model, the `protected` annotation needs to be understood by comparison to the case of full Modelica origin.
+When the Base Modelica is not generated from a full Modelica model, the `protected` annotation needs to be understood by comparison to the case of full Modelica origin.
 
 For example, consider the following full Modelica model:
 ```
@@ -67,8 +67,8 @@ protected
 end M;
 ```
 
-Note that `p` can only be modified when extending the model, and that the `Protected = true` annotation does not enforce this constraint in Flat Modelica.
-Hence, the correct conversion to Flat Modelica needs to combine `Protected = true` with treatment similar to a parameter declared `final`:
+Note that `p` can only be modified when extending the model, and that the `Protected = true` annotation does not enforce this constraint in Base Modelica.
+Hence, the correct conversion to Base Modelica needs to combine `Protected = true` with treatment similar to a parameter declared `final`:
 ```
 model 'M'
   parameter Real 'p' annotation(Protected = true);
@@ -91,12 +91,12 @@ protected
   M m2;
 end N;
 ```
-In Flat Modelica, the level of the original protected section is lost:
+In Base Modelica, the level of the original protected section is lost:
 ```
 package 'M'
   model 'M'
     Real 'm1.x';
-    Real 'm1.p' annotation(Protected = true); 
+    Real 'm1.p' annotation(Protected = true);
     Real 'm2.x' annotation(Protected = true);
     Real 'm2.p' annotation(Protected = true);
   end 'M';
@@ -106,4 +106,4 @@ end 'M';
 
 ## Vendor annotations
 
-Flat Modelica allows for vendor-specific annoations in the same way as in full Modelica.
+Base Modelica allows for vendor-specific annoations in the same way as in full Modelica.