MetaModelica extension: bidirectional variables

[Martin Sjölund]

One annoying thing with MetaModelica is the inability to assign to input variables, and the fact that you need different names for the input and output variables when traversing data structures.

I propose a syntactic sugar for handling bidirectional variables:

function f
  input output Exp exp;
  input output Integer i;
algorithm
  exp := match exp
    case ICONST() then ICONST(exp.value+i);
    else exp;
  end match;
end f;

Which is almost equivalent to:

function f
  input Exp $in_exp;
  input Integer $in_i;
  output Exp exp=$in_exp;
  output Integer i=$in_i;
algorithm
  exp := match exp
    case ICONST() then ICONST(exp.value+i);
    else exp;
  end match;
end f;

(The difference being that the type of the function would keep the original names when using named arguments for calling the function).

The benefit would be shorter code and better names. There would be no need to use prefixes in and out to differentiate between two local variables.

[Martin Sjölund]

And of course, no more code using things like: f(inExp=ICONST(1)) (we already know we are passing an input variable).

[Rüdiger Franke]

Assignments to input variables increase possible side effects and surprises by people using such a function. Compared to other languages, Modelica declares all inputs implicitly const inside functions. When widening the features of MetaModelica, you might force the callee to explicitly indicate that he knows what he is doing.

C#, for instance, has out and ref qualifiers for function arguments. They must be used both: in the declaration of a function and during the call of the function, like

f(out a);

Constant inputs helps e.g. in matrix functions. They also helps in setting up an equation structure

a = f(b);

instead of

a = b;
f(out a);

???

[Martin Sjölund]

This is not call by reference; there will be no side-effects. It is still call by value and a copy will be made in the function. It is just syntactic sugar to make it more convenient to write functions.

[Martin Sjölund]

This is handled in ​PR#470. You can also see one example of what the code looks like ​here. (To be merged after 1.9.4 release, together with a new bootstrapping tarball if we agree this is a useful extension)

[Rüdiger Franke]

I wonder if the confusion introduced with this extension is really worth it. Speaking of myself, I don't spend much time in adding an additional line for an output. I'm using most time for trying to understand what's going on in the code. This time would increase with the proposed extension.

[Martin Sjölund]

I'm using most time for trying to understand what's going on in the code.

For myself, I always get confused about what to name the input and output. The inExp/outExp thing really bothers me, because I want to use the name exp in the actual code. And when moving code around, you tend to get things wrong because the first occurance of exp should be inExp, while all the other ones should be outExp. There are many fewer things that can go wrong with this extension and should improve readability, making understanding the code faster, not slower.

[Rüdiger Franke]

The inExp/outExp thing is a good argument. Also the qualifiers "input output" look nicer than "bidirectional" proposed in this ticket initially.