Breaking ModelicaServices cyclic dependency on Modelica

[sjoelund]

Currently, ModelicaServices is backwards compatible with older versions of itself and has noneFromVersion conversion annotations. However, it has a uses-annotation on Modelica which in turn has a uses-annotation on ModelicaServices. This means that it is not possible to have for example Modelica 3.2.2 loaded with ModelicaServices 3.2.3 or 4.0.0.
There are some interfaces in MSL that are used as well as some icons, but I believe these would work just as well if they were put into ModelicaServices and if the uses-annotation was removed, it would instantly be possible to load a more recent ModelicaServices if needed.
The disadvantage would be that some form of sanity check from MSL's point of view would be lost and it would need to rely on ModelicaServices version/conversion annotations being correct.

This might for example make it possible for a Modelica tool vendor to ship only 1 version of ModelicaServices that is compatible with all previous MSL versions using ModelicaServices. It would also make package management easier.

I should note that I have not tested such changes, but would like a discussion to see if this would be something we are interested in changing (and would perform tests on any pull request I create for this).

[HansOlsson]

In parts that seems like a good idea, and tool vendors may already be able to that in the versions they provide.

The question is more whether we should do that in the "standard" version, or just have it as a suggestion.

Note that tool implementations normally also add implementations, and in some cases those may depend on other classes in MSL that may or may not be changed between versions; even something as innocent as Position was moved between 3.2.3 and 4.0.0, a tool may circumvent that by "reimplementing" it in ModelicaServices (a Real with unit="m").

Thus it might be simpler to just add that a tool may do it, possibly with the comment above.
(I can't remember if we already tried that in Dymola, and whether there were any issues or not.)

[sjoelund]

From my point of view it would be nicer to have it in the default version. I suppose that's because we script most of the changes to services. It's just a small patch + some commands:

https://github.com/OpenModelica/OpenModelica-ModelicaStandardLibrary/blob/OM/maint/4.0.x/ModelicaServices.patch

setClassComment(ModelicaServices, "ModelicaServices (OpenModelica implementation) - Models and functions used in the Modelica Standard Library requiring a tool specific implementation");
setComponentModifierValue(ModelicaServices, target, $Code(="OpenModelica"));
setComponentModifierValue(ModelicaServices.Machine, Integer_inf, $Code(=OpenModelica.Internal.Architecture.integerMax()));
addClassAnnotation(ModelicaServices.ExternalReferences.loadResource, annotate=__OpenModelica_EarlyInline(true));

One could also consider having some PartialModelicaServices package if that part seems too big, and let it contain the things that vendors are not supposed to change. Because, yes... It would need to have its own types for those common visualizers. That way you could also ensure that the interface is adhered to.

[sjoelund]

Thus it might be simpler to just add that a tool may do it, possibly with the comment above.
(I can't remember if we already tried that in Dymola, and whether there were any issues or not.)

I think that you then might end up with models from that tool having annotations like uses(Modelica(version="3.2.3"), ModelicaServices(version="4.0.0")), which other tools would not be able to handle. We have seen models like that for various reasons.

[hubertus65]

I'd prefer not to have cyclic dependencies, but I have no strong opinion on how to solve them. Your suggestion looks pragmatic to me.