Support application of implicit conversions in physunits language#1754
Draft
kbirken wants to merge 14 commits intomaintenance/mps20241from
Draft
Support application of implicit conversions in physunits language#1754kbirken wants to merge 14 commits intomaintenance/mps20241from
kbirken wants to merge 14 commits intomaintenance/mps20241from
Conversation
…roots from old location (#1675).
…re/physunits_implicit_conversions_et_al_1675 # Conflicts: # CHANGELOG.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces execution of implicit conversion rules as described in #1675. Before, only implicit conversions based on different unit prefixes were supported. The
implicitkeyword 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 as120 s + 60 s, instead of2 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:
It would be possible in future to make this strategy configurable via extension point
IUnitLangConfig. Right now the following aspects can be configured:IUnitLangConfig.implicitConversionIsEnabled[At]the implicit conversion mechanism can be switched on/off as a whole.IUnitLangConfig.getUnitStandardizera 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
TaggedExpressionorBinaryExpressionrule. 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 shas to be evaluated as60 s > 55 s, but the interpreter rule for>first will evaluate the left operand to runtime value1to know how to proceed. However, then it's too late to change the value of the operand again.Thus, when encountering a
TaggedExpressionwith 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.physunitsfor 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 modeltest.ts.expr.os.phyunitscould 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.