Skip to content

Support application of implicit conversions in physunits language#1754

Draft
kbirken wants to merge 14 commits intomaintenance/mps20241from
feature/physunits_implicit_conversions_et_al_1675
Draft

Support application of implicit conversions in physunits language#1754
kbirken wants to merge 14 commits intomaintenance/mps20241from
feature/physunits_implicit_conversions_et_al_1675

Conversation

@kbirken
Copy link
Copy Markdown
Member

@kbirken kbirken commented Apr 16, 2026

This PR introduces execution of implicit conversion rules as described in #1675. Before, only implicit conversions based on different unit prefixes were supported. The implicit keyword for conversion rules basically had no effect at all.

Functionality

The implicit conversion rules are applied in the typesystem and during evaluation in the interpreter. If more than one implicit conversion rule applies, the priority is being used to determine which one is applied. E.g., for the expression 2 min + 60 s, the implicit conversion rule from minutes to seconds will have a higher priority. Thus, the expression will be interpreted as 120 s + 60 s, instead of 2 min + 1 min. This can be used also to prevent rounding issues.

Implicit conversions will be applied to plus- and minus-expressions, as well as to binary comparison expressions like <, =, and so on. For multiplication and division, implicit conversion is not necessary.

For any of these binary expressions, the following strategy is being executed:

  1. If there is an implicit conversion for the left operand to match the unit of the right operand, but not vice versa, then this conversion is applied.
  2. If there is an implicit conversion for the right operand to match the unit of the left operand, but not vice versa, then this conversion is applied.
  3. If there are implicit conversions for both directions, the one with higher priority will be applied.
  4. If there are no direct implicit conversions between left and right operand, check if both operands can be converted to a common standard unit (e.g., SI base unit).

It would be possible in future to make this strategy configurable via extension point IUnitLangConfig. Right now the following aspects can be configured:

  • Via IUnitLangConfig.implicitConversionIsEnabled[At] the implicit conversion mechanism can be switched on/off as a whole.
  • Via IUnitLangConfig.getUnitStandardizer a strategy can be configured which determines the standard unit for a given unit. The default is to use the SI-system for determining standard units.

Implementation remarks

Interpreter

In the interpreter it wasn't possible to do the conversion locally when evaluating a single TaggedExpression or BinaryExpression rule. The reason for this is that implicit conversions not only affect the type of an operand, but also its runtime value. The runtime values do not have a physical unit anymore.

Example: The expression 1 min > 55 s has to be evaluated as 60 s > 55 s, but the interpreter rule for > first will evaluate the left operand to runtime value 1 to know how to proceed. However, then it's too late to change the value of the operand again.

Thus, when encountering a TaggedExpression with a unit, the interpreter will go up the expression's AST to compute the implicit conversion rules to be applied and their impact. In future this approach might be too restrictive for modular extensions of the interpreter. Maybe an extension to the interpreter framework can then be implemented allowing this kind of pre-evaluation analysis in a more controlled way.

Constraint solver

In IETS3.Core, we will need some fancy translation of expressions which trigger implicit conversion rules when transforming these expressions as input for a solver. Some helper classes added by this PR are designed so that this is possible (sharing of code between typesystem, interpreter, and solver).

New test solution for physunits

Additionally, a new test solution test.org.iets3.core.expr.typetags.physunits for the physunit language has been created. Some test cases (related to interpreter evaluation and typesystem compution of expressions) have been moved to the new test solution and cleaned up. Some messy testcase root nodes from the old physunits test model test.ts.expr.os.phyunits could thus be removed, actually replaced by more comprehensive tests without model check errors in the test models. The goal is to move all tests from the old location to the new test solution and improve them while doing so. This will not be done in one step, there will be subsequent PRs.

This solves #1675.

@kbirken kbirken self-assigned this Apr 16, 2026
@kbirken kbirken requested a review from dbinkele April 16, 2026 18:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant