Unitful literals

[henrikt-ma]

This is the design for attaching units to literals that was discussed at the most language design meeting in Linköping held in March this year. The proposal is an alternative to #3668, with emphasis on simple design, ease of use, and human readability.

This design was originally implemented in SimulationX, and later given two parallel implementations in System Modeler - one for testing it in regular Modelica expressions, and one for (undocumented) use in vendor-specific annotations.

[henrikt-ma]

The ease of use and readability provided by this proposal is important for the acceptance of this as a correct way to address the unit error in a situation like this:

Real distance(unit = "m") = 100;
Real v(unit = "m/s") = distance / 9.58; // Unit error
Real v(unit = "m/s") = distance / 9.58's'; // Correct

This PR makes no changes to unit checking; the following should be rejected as inconsistent:

Real distance(unit = "m") = 1000'cm';

[HansOlsson]

This PR makes no changes to unit checking; the following should be rejected as inconsistent:

Real distance(unit = "m") = 1000'cm';

The latter isn't even close to beginning to meaningfully adress the actual problems this would introduce in practice.
Please look at actual models as in MSL.

[HansOlsson]

To avoid merging by mistake:
As repeatedly indicated this makes it easy to introduce non-coherent units, which requires a detailed analysis.

[henrikt-ma]

It is hard to think of a programming language where units and unit checking matter more than in Modelica. It is just silly that the language is lacking this basic construct of constructing unitful literals.

Applications are everywhere:

• Making expressions and equations with literals unit consistent without the need to introduce protected helper variables just to attach the missing units.
• Avoiding dangers of the wildcard effect, see example below.
• Last but not least, clarity; even if an expression or equation with literals is unit consistent according to the unstated unit checking rules of Modelica, making the implicit units of the literals explicit is a great enhancement of clarity.

Example of the day:

model AcuteAngle
  parameter Modelica.Units.SI.Angle a = 0;
equation
  assert(abs(a) < 90, "The angle must be acute.");
end AcuteAngle;

Due to the lack of clarity and the wildcard effect, the error above is easy to make, and the model developer who knows that the model only works for acute angles might fail to check that the assertion actually works.

If the developer would have used a unitful literal instead, a unit inconsistency would have revealed the problem:

  assert(abs(a) < 90'deg', "The angle must be acute.");

When corrected, the attached unit adds clarity and removes any uncertainty related to the wildcard effect:

  assert(abs(a) < 1.57'rad', "The angle must be acute.");

If the modeler decides to use Angle_deg instead (maybe it is the angle of a FixedRotation), the need to also update the assert would be detected.

[henrikt-ma]

As repeatedly indicated this makes it easy to introduce non-coherent units, which requires a detailed analysis.

Let's not pretend that we can't perform a decent amount of unit checking, and let's not assume that the feature would be massively misused to exploit any gaps we still have in the unit checking semantics.

The alternative, using numeric literals without unit and relying on the wildcard effect is so much worse than the tiny risk of introducing a unitful literal with non-coherent unit in a place where it wouldn't be caught by unit checking.

[HansOlsson]

The alternative, using numeric literals without unit and relying on the wildcard effect is so much worse than the tiny risk of introducing a unitful literal with non-coherent unit in a place where it wouldn't be caught by unit checking.

The original design was to have equations in coherent units; and have non-coherent units in the user interface at the boundary.
That design doesn't have any of those issues, and was made exactly because units matter.

Apart from that the previously raised issues with temperatures, and rotations are still unresolved.

[henrikt-ma]

I think we need external input to make progress here. @casella, @AHaumer, @GallLeo, @hubertus65, would you be interested in joining us for a session about the pros and cons of being able to express unitful literals in expressions and equations?

[HansOlsson]

I think we need external input to make progress here.

I don't see it as meaningful to involve more people when there are still no answers regarding how possibly non-coherent units in equations would actually work, especially for temperatures and rotations.

[HansOlsson]

I think we need external input to make progress here.

I don't see it as meaningful to involve more people when there are still no answers regarding how possibly non-coherent units in equations would actually work, especially for temperatures and rotations.

It's also misleading to tell others that the issue is 'unitful literals' when the problem is that it's suddenly easy to add possibly non-coherent units like 2 'kW', 50 'Hz', 12 'rad/s', or 200 'degC' inside equations, and then rely on some yet-to-be-specified unit-check to figure out that it wasn't the right unit.

I have still not seen anything meaningful addressing those issues, or how it would work in practice.

Just to be clear: the proposal isn't to allow 2 'kW' as a short-cut for 2e3 'W' inside equations, as most users would expect based on the rest of the user experience (that variant would also have some problems temperatures and rotations), but as something having unit "kW".