MCP-0007: Match Expressions and Recursive Records

[modelica-trac-importer]

Reported by petfr on 3 Jun 2014 08:42 UTC

The MCPI-0007 Match expressions and Recursive Records design
proposal is discussed
at this ticket.

The most recent version v5, makes a comparison, pros and cons,
between the uniontype and the case record design alternatives.

Associated files are also at the the MCPI trunk.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1503

[modelica-trac-importer]

Comment by choeger on 3 Jun 2014 09:29 UTC
Thanks for the update.

A few remarks:

• We do not have an object model (i.e. abstract syntax) for our values. That means the decision of whether a pattern does match or not, will only be defined informally. I consider this a possible source of future incompatibilities. The classic approach is to define a match primitive expression and its semantics formally and then define pattern matching on top of that.
• Quoting the MCPI:

However, from experience with MetaModelica in the Modelica community consisting mostly of engineers, the pattern variable feature seems to be rather difficult to grasp for people in that community, and also makes the code harder to read if one is not used to that mechanism. (But the code can be more concise and easier to read if one is used to that feature). Instead we use standard dot notation to extract field values.

I think this is a very weak reason for implementing the matching in a way practically noone else does it.

• Even if it was true, that engineers are for some strange reason incompatible to pattern matching, the proposed solution implies a very special type-checking rule:

  case DIVop() then eval(x.exp1) / eval(x.exp2);
  case NEGop() then –eval(x.exp);

Obviously the intention is that depending on the selected pattern, either x.exp1 or x.exp is a valid expression, but not both. This is -at least- another divergence from classical algebraic datatypes, with probably consequences for type-system soundness.

• There seems to be the intention of allowing not just constructors but also (at least literal) expressions in the pattern language. There should be a definition of the matching syntax here (which probably requires a definition of some polymorphic equality)
• Other languages (e.g. ML) make a syntactical distinction between Variants (and constructors) and type-names (and variables). Although it might seem annoying, it is a simnplification when it comes to the definition of the semantics and/or correctness checks.

Conclusion: The proposal seems to suffer from a minor case of the NIH syndrome ;). I'd prefer to not vary from widely accepted and tested practice without strong reason.

[modelica-trac-importer]

Comment by hansolsson on 18 Jun 2014 07:11 UTC
I agree with the previous comment, and consider the case:

match x in fooBar()
case RCONST() then x.expr1;
case ADD() then x.expr1+x.expr2;

To me (and others) this half-pattern matching is confusing.

If proper pattern matching leads to problems I would propose a different variant to make it clear that these are not patterns for pattern matching and found some inspiration in Modula-2:

One could either use a different keyword for the match:

matchtype x in fooBar()
case RCONST then x.expr1;
case ADD then x.expr1+x.expr2;

alternatively add the keyword for the cases:

match x in fooBar()
if type RCONST then x.expr1;
if type ADD then x.expr1+x.expr2;

The second approach would allow us to combine patterns and type-matching:

match x in fooBar()
if type RCONST then x.expr1;
if ADD(a,a) then 2*a;
if type ADD then x.expr1+x.expr2;

The names “case type” or “type case” would be too confusing to me; but it is just naming.

[modelica-trac-importer]

Comment by petfr on 20 Nov 2014 10:11 UTC
From rfranke, via e-mail:

meanwhile I also remembered the discussed "killer feature"
motivating MetaModelica: It was the ability to automatically adapt
existing models to changes in a used library. For instance I replaced
all "dqo" with "dq0" in release 0.3 of PowerSystems - just google for
dq0 and you find the right things - google for dqo and you find a lot of
misleading stuff as well. Would be great if there was a standardized way
to provide a script adapting all models that use an old version of
PowerSystems .

Generally I think that the missing feature "conversion scripts" hinders
a lot of innovation in the current development of MSL.

[modelica-trac-importer]

Comment by hansolsson on 20 Nov 2014 11:14 UTC
Replying to [comment:3 petfr]:

From rfranke, via e-mail:

meanwhile I also remembered the discussed "killer feature"
motivating MetaModelica: It was the ability to automatically adapt
existing models to changes in a used library. For instance I replaced
all "dqo" with "dq0" in release 0.3 of PowerSystems - just google for
dq0 and you find the right things - google for dqo and you find a lot of
misleading stuff as well. Would be great if there was a standardized way
to provide a script adapting all models that use an old version of
PowerSystems .

Generally I think that the missing feature "conversion scripts" hinders
a lot of innovation in the current development of MSL.

I believe that is a separate issue.
There is a topic for standarizing those "conversion scripts" (at least the currently useful ones, we don't need the special cases for Modelica 1->2 anymore), and pattern matching should not be a blocker for discussing that.

Lots of tools for different languages have such "refactoring" possibilities, without relying on match expressions.

For Modelica I know that Dymola and Dymola Behavior Modeling App have settings such that just changing the name of the variable (or class) automatically updates all existing uses and also creates the "conversion script", and I would assume it is similar for the other Modelica tools.

Yes, I can see that pattern matching would make it easier to write a "refactoring package" that a tool could use to implement the "conversion script" handling - but the user just wants the conversion to work automatically.

[modelica-trac-importer]

Comment by sjoelund.se on 20 Nov 2014 12:06 UTC
Replying to [comment:4 hansolsson]:

Dymola and Dymola Behavior Modeling App have settings such that just changing the name of the variable (or class) automatically updates all existing uses and also creates the "conversion script", and I would assume it is similar for the other Modelica tools.

Yes, I can see that pattern matching would make it easier to write a "refactoring package" that a tool could use to implement the "conversion script" handling - but the user just wants the conversion to work automatically.

Exactly. The "conversion script" generated by Dymola will not work automatically in any other tool (that I know of). If there existed a standardised representation for the abstract syntax tree, there could be a library, say, ModelicaConversions that would make it very simple to create conversion scripts.

myConversion.mos:

ast := getLoadedAst(); // Some built-in
ast := ModelicaConversions.rename(ast=ast, fromName="Modelica.Blocks.Continuous.Integrator.k", toName="Modelica.Blocks.Continuous.Integrator.k1", classesToUpdate={"MyLibrary"});
updateLoadedAst(ast); // Modify the loaded ast to be the updated one

And the library would contain the actual code to update the abstract syntax tree. It is a very nice application anyway.

[modelica-trac-importer]

Comment by sjoelund.se on 20 Nov 2014 12:10 UTC
For the OpenModelica prototype on how match-expressions and union types work:
Basic-Exercise-MetaModelica.onb
(The latest nightlies crash for the invalid cons-expressions, so simply don't evaluate the offending cell)

Evaluate cells by marking the cell and pressing shift+enter.

[modelica-trac-importer]

Comment by hansolsson on 20 Nov 2014 14:47 UTC
Replying to [comment:5 sjoelund.se]:

Replying to [comment:4 hansolsson]:

Dymola and Dymola Behavior Modeling App have settings such that just changing the name of the variable (or class) automatically updates all existing uses and also creates the "conversion script", and I would assume it is similar for the other Modelica tools.

Yes, I can see that pattern matching would make it easier to write a "refactoring package" that a tool could use to implement the "conversion script" handling - but the user just wants the conversion to work automatically.

Exactly. The "conversion script" generated by Dymola will not work automatically in any other tool (that I know of). If there existed a standardised representation for the abstract syntax tree, there could be a library, say, ModelicaConversions that would make it very simple to create conversion scripts.

My point is that creating the ModelicaConversions library is not simple even with match expressions and a normal ast-library (and as far as I know a standarized ast-library is not on the agenda, and not planned for Modelica 3 as far as I know).

Thus we shouldn't have this topic blocking the discussion of conversion scripts, and we shouldn't try to sell match-expressions as the solution to the problem of conversion scripts.

And the library would contain the actual code to update the abstract syntax tree. It is a very nice application anyway.

I would say that the conversion scripts are not good at demonstrating an ast-library, since they sort of operate on the ghost of the ast of the last version.

During normal refactoring you can rename "dqo" to "dq0" in all classes by looking up "dqo" and atomatically replacing them all by "dq0" (that would be a good example of using an ast-library), but when using the conversion script we only have the new version and cannot find the "dqo" to replace.

Yes, a good ast-library may have the primitives to find them - but I wouldn't call it a good example of the use of the ast-library.

Similarly the procedural style of renaming items one-by-one by calling ModelicaConversions.rename is both a bit inefficient and would require that the conversion script is ordered; i.e. users could break a sequence of calls of ModelicaConversions.rename when they rearrange them to clean them up.

[modelica-trac-importer]

Modified by otter on 18 Sep 2015 10:16 UTC