Revisit impure - due to errors

[HansOlsson]

Looking at MSL 4.1.0 due to #3706 I realized that we didn't get impure right in the library, and the current semantics problematic (unless you use a rather odd interpretation).

With the current rules if you don't add pure/impure everywhere it just works (with diagnostics), and external functions are kind of assumed to be impure.

The problem is then that you try to be good and add impure to the external calls. The intent is then that callers should be declared as impure (etc), which clearly would be good. However, we failed to do that in MSL as corrected by modelica/ModelicaStandardLibrary#4686 - and to me it doesn't make sense that trying to be good by adding impure turn a diagnostics for deprecated behavior into an error.

The likely consequence is that people will be reluctant to add impure to external functions, since there will be too much down-stream work and/or complaints, or that tools will not implement the semantics (arguing that the proposed behavior is the "correct interpretation").

Currently it says:

A deprecated semantics is that external functions (and functions defined in Modelica directly or indirectly calling them) without pure or impure keyword are assumed to be impure, but without any restriction on calling them.

My first proposal is something along the lines for:

A deprecated semantics for functions without pure or impure is that they assumed to be impure, but without any restriction on calling them for the following cases: external functions and functions defined in Modelica directly or indirectly (through functions without the pure keyword) calling external functions without pure keyword.

And remove the "However, since functions as default are pure it is not recommended to explicitly declare them as pure".

The second proposal would be to more completely revisit pure/impure.

[henrikt-ma]

The problem is then that you try to be good and add impure to the external calls. The intent is then that callers should be declared as impure (etc), which clearly would be good. However, we failed to do that in MSL as corrected by modelica/ModelicaStandardLibrary#4686 - and to me it doesn't make sense that trying to be good by adding impure turn a diagnostics for deprecated behavior into an error.

The likely consequence is that people will be reluctant to add impure to external functions, since there will be too much down-stream work and/or complaints, or that tools will not implement the semantics (arguing that the proposed behavior is the "correct interpretation").

Of course, library developers will not care about making their libraries conform with the specification unless they have good tool support – we need to recognize the need for tool support to make the transition happen. In my opinion, a tool is not helping the transition if the purity errors cannot be treated as warnings until we have managed to develop the specification in conjunction with adaptation of major libraries (the MSL in particular) to a point we firmly believe worth committing to. Further, until the MSL has been adapted to the specification, I find it unlikely that developers of other libraries would start to care.

Currently, System Modeler is not helpful in this regard, since the questions surrounding purity in the specification and the lack of adaptation in libraries means that implementing the checks mostly would initially be a feature only used by MSL library developers, and System Modeler is traditionally not used much by these developers. If we saw that the MSL was really starting to adapt, matters would be different, and I would expect that we would then get purity in System Modeler (with user control over how violations should be treated).

[HansOlsson]

The problem is then that you try to be good and add impure to the external calls. The intent is then that callers should be declared as impure (etc), which clearly would be good. However, we failed to do that in MSL as corrected by modelica/ModelicaStandardLibrary#4686 - and to me it doesn't make sense that trying to be good by adding impure turn a diagnostics for deprecated behavior into an error.
The likely consequence is that people will be reluctant to add impure to external functions, since there will be too much down-stream work and/or complaints, or that tools will not implement the semantics (arguing that the proposed behavior is the "correct interpretation").

Of course, library developers will not care about making their libraries conform with the specification unless they have good tool support – we need to recognize the need for tool support to make the transition happen. In my opinion, a tool is not helping the transition if the purity errors cannot be treated as warnings until we have managed to develop the specification in conjunction with adaptation of major libraries (the MSL in particular) to a point we firmly believe worth committing to. Further, until the MSL has been adapted to the specification, I find it unlikely that developers of other libraries would start to care.

Well, my point is that with the current specification if you adapt one library to specify impure/pure all down-stream libraries will go from warning to error; and thus people will be reluctant to start.

That is assuming tools implement those semantics, in reality tools may implement something more forgiving and then we should specify that.

I'm not saying that the proposed change is perfect, just that it makes it easier to move forward - and I could see tools implementing these semantics without making users angry.

The current situation is clearly bad: neither tools nor MSL follow the specification; and there's no easy way forward for either.

[HansOlsson]

@HansOlsson to provide PR