Update purity exception for Streams.print

[henrikt-ma]

In https://specification.modelica.org/master/functions.html#pure-modelica-functions there is the following exception for print:

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. Except for the function Modelica.Utilities.Streams.print, a diagnostic must be given if called in a simulation model.

The problem is that Modelica.Utilities.Streams.print is nowadays explicitly marked impure, so the exception is only causing confusion at the moment.

This PR updates the specification so that it applies to the current MSL. The most important part, that there is a loophole for calling print anywhere, still applies to older MSL where print is not explicitly declared impure. The only change for older MSL is that the deprecated semantics demands a diagnostic in this case – I find it better that tools act on their own on this matter than to elaborate the rules for diagnostics in the specification.

[HansOlsson]

In https://specification.modelica.org/master/functions.html#pure-modelica-functions there is the following exception for print:

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. Except for the function Modelica.Utilities.Streams.print, a diagnostic must be given if called in a simulation model.

The problem is that Modelica.Utilities.Streams.print is nowadays explicitly marked impure, so the exception is only causing confusion at the moment.

This PR updates the specification so that it applies to the current MSL.

I agree that the current status is not good, but as far as I understand this change mean that we have a permanent exception for Modelica.Utilities.Streams.print, right?

I think we need to analyze it in more detail:

• How common is such use of print?
• How does it generalize? The problem I see with this change is that if someone wants to print (e.g., for debugging; even though print-debugging is often seen as a bad idea) they may alternatively use a function calling print. In that case it seems they must declare that function pure (so that it can be called), and it seems the intent is that such a pure function may call print without any needed diagnostics. That print is impure and the user-written replacement is pure does not look nice.

Looking at MSL I see some of the problems, and also that some of uses of print should likely be replaced by assert-warnings.

[HansOlsson]

I investigated MSL regarding this.

This first lead to the proposed changes:

• Use assert-warning instead: Prefer warning instead of print message ModelicaStandardLibrary#4685
• Declare impure where possible: Declare impure ModelicaStandardLibrary#4686

And also the conclusion:

• I don't see the need to continue to have an exception for print.
• The current rules are really problematic for other cases.

I thus believe we should revisit pure and impure once more.

Specifically we have the issue that if one decides to declare an external function as impure (which it often is) one then needs to declare every caller as impure (with some rare exceptions).

That downstream change will be a problem for any library developer, and we didn't even do it correctly for MSL. That means that the simplest solution for users is to not declare an external function as impure, and just rely on the compatibility handling, which seems counter-intuitive.

I believe the best way forward is to change so that functions defined in Modelica without pure/impure that directly or indirectly call an external function declared as impure will be assumed to be impure. (But without allowing them to be called everywhere.)

[HansOlsson]

I agree that the current situation isn't good.
But I don't think we should to keep the exception for print.
However, I also think that we need to revisit the impure handling, and will open a new issue.