Reconsider algebraic variables with int type and constant value getting explicit range
Introduction
Algebraic variables with int
type a constant value get an explicit range. The following:
alg int x = 5;
is declared with an int
type. The type checker determines that the type of the value is int[5..5]
. In this case gives variable x
an int[5..5]
type.
The type checker thus changes the declared type to an inferred more specific type. If you save this model, you get:
alg int[5..5] x = 5;
Pretty print the model thus changes the type, as the pretty printer involves loading a model (including type checking) and saving it again.
Earlier discussion
We discussed this in issue #105 (closed).
From #105 (comment 32987)
[...] what is the meaning of:
alg int n = 1;
alg int[1..1] n = 1;
alg int[-max_int+1..max_int] = 1;
I see the second case as the meaning: declaring
alg int n = 1;
means that the model should be able to accept anyint
value forn
, and currently the value ofn
is set to1
.[...]
Finally, I can see that changing this would change the language and has a high potential of breaking existing models, as Dennis mentioned, and I am not in favor of a quick fix.
From #105 (comment 32989)
Finally, I can see that changing this would change the language
You mean remove setting the range after pretty printing? If it really is a problem, we should discuss that in a separate issue.
From #105 (comment 32996)
You mean remove setting the range after pretty printing?
I did not even know that
alg int x = 1
is transformed intoalg int[1..1] x = 1
by pretty printing. Just checked and I must say that is not at all what I had expected.I meant more in general that any change that changes the language and potentially breaks existing models should be very carefully considered.
If it really is a problem, we should discuss that in a separate issue.
I think that what we are discussing here is not about the specific error anymore, but is more fundamental about the semantics and implications of ranged integers.
I've had problems in the past. For example,
alg int x = 3
can be merged withinput int x
, via the CifMerger. However, if it is converted toalg int[3..3] x = 3
it can no longer be merged. Pretty printing should not change merge compatibility.I completely agree.
The question
We have two options:
- Keep it as is.
- Don't let the type checker change the type of algebraic variables in such cases.