Clarify in what ways names like Real are different from keywords

[henrikt-ma]

Consider the following model:

model EnumeratorsAreNotElements
  type Types = enumeration(Real, Integer, Boolean);
  Types x = Types.Real;
end EnumeratorsAreNotElements;

My reading of the specification suggests that this is a valid model:

The names Real, Integer, Boolean and String are reserved such that it is illegal to declare an element with these names.

Hence, I think the example could be added as an example that clarifies in what ways these names are different from keywords. Maybe there are other examples worth mentioning as well?

(Ideally, I would have liked these names to be keywords, so that we didn't have to add this kind of clarifications at all.)

[HansOlsson]

I don't see that it was the intention to allow such models, so we should clarify that.

As I understand the reason Real isn't a keyword is that the current specification contains a definition of type Real ... end Real, which obviously wouldn't work if it were a keyword; and additionally it would be messy to consistently include them in the grammar.

[henrikt-ma]

As I understand the reason Real isn't a keyword is that the current specification contains a definition of type Real ... end Real, which obviously wouldn't work if it were a keyword;

But that's just pseudo-code, so it wouldn't be a problem.

and additionally it would be messy to consistently include them in the grammar.

Isn't it as simple as just adding the built-in types as alternatives to IDENT in declaration?

[HansOlsson]

As I understand the reason Real isn't a keyword is that the current specification contains a definition of type Real ... end Real, which obviously wouldn't work if it were a keyword;

But that's just pseudo-code, so it wouldn't be a problem.

But we would need an explanation for it; so I don't view this as top-priority.

and additionally it would be messy to consistently include them in the grammar.

Isn't it as simple as just adding the built-in types as alternatives to IDENT in declaration?

Ehmm.... No, that's one place we don't want it as alternative to IDENT. Adding it as an alternative to name in type-specifier would make more sense.

[henrikt-ma]

As I understand the reason Real isn't a keyword is that the current specification contains a definition of type Real ... end Real, which obviously wouldn't work if it were a keyword;

But that's just pseudo-code, so it wouldn't be a problem.

But we would need an explanation for it; so I don't view this as top-priority.

Not saying it is a top priority. Just saying it is an easy fix we can do to express the intention in best and most natural way. Tools could also get away with almost no change, until they find the proper time – if ever – to make internal representations more coherent with the formal structure of the langue.

and additionally it would be messy to consistently include them in the grammar.

Isn't it as simple as just adding the built-in types as alternatives to IDENT in declaration?

Ehmm.... No, that's one place we don't want it as alternative to IDENT. Adding it as an alternative to name in type-specifier would make more sense.

See? I told you fixing the grammar would be easy. :)

[henrikt-ma]

I suggest that we plan this for the next phone meeting, as the problem has come into a new light with the two categories we now use for syntax highlighting of keywords. I think that Real and friends would fit nicely in the morekeywords=[1] category, together with things like parameter and input.

(Setting milestone accordingly, please remove if it doesn't fit the agenda.)

[HansOlsson]

I suggest that we plan this for the next phone meeting, as the problem has come into a new light with the two categories we now use for syntax highlighting of keywords. I think that Real and friends would fit nicely in the morekeywords=[1] category, together with things like parameter and input.

To me that's a separate issue and I don't think it is good. The disadvantage is that declarations using builting-types (Real, Integer) will look different from declarations using user-defined types. If I see code such as:

  parameter SI.Voltage OCVmax(final min=0) "OCV at SOC = SOCmax"
    annotation(Dialog(group="OCV versus SOC"));
  parameter SI.Voltage OCVmin(final min=0, start=0) "OCV at SOC = SOCmin"
    annotation(Dialog(group="OCV versus SOC", enable=useLinearSOCDependency));
  parameter Real SOCmax(final max=1)=1 "Maximum state of charge"
    annotation(Dialog(group="OCV versus SOC"));
  parameter Real SOCmin(final min=0)=0 "Minimum state of charge"
    annotation(Dialog(group="OCV versus SOC"));

it is good to visually see the similarity between the declarations, and easily find two important pieces of information - name and type. If different types have too different syntax highlighting that no longer works. Unfortunately we cannot fully handle it with the current syntax highlighter, since user-defined types and names are the same and Real is subtly different; but that still seems something to strive for.

[HansOlsson]

Proposal, modify text to:

The names Real, Integer, Boolean and String are reserved such that it is illegal to declare an element or enumeration literal with these names.

[henrikt-ma]

it is good to visually see the similarity between the declarations, and easily find two important pieces of information - name and type. If different types have too different syntax highlighting that no longer works. Unfortunately we cannot fully handle it with the current syntax highlighter, since user-defined types and names are the same and Real is subtly different; but that still seems something to strive for.

We already recognize Real as something special, unlike SI.Voltage which is not recognized as having a special role in the language. A syntax highlighter that would use the same style for Real and SI.Voltage today could keep doing so even if Real was made a keyword. To me, the important thing here is that we call the things keyword when they actually act as full-fledged keywords, instead of calling them identifiers but with the same constraints as if they were keywords. Playing tricks with the language specification like this in order to achieve some special syntax highlighting doesn't seem like the right approach.

[HansOlsson]

As I understand the reason Real isn't a keyword is that the current specification contains a definition of type Real ... end Real, which obviously wouldn't work if it were a keyword;

But that's just pseudo-code, so it wouldn't be a problem.

Actually that definition of Real can and is used as real code as well in some tools; so changes would be needed.

[henrikt-ma]

Actually that definition of Real can and is used as real code as well in some tools; so changes would be needed.

Sounds like a tool issue.

[henrikt-ma]

I find it relevant to also compare with other languages. In C/C++/Java, one cannot give different meanings to the primitive types such as int or double, and these are considered keywords accordingly.

In languages where it is possible to shadow built-in types, they are of course not keywords. If Real shouldn't be a keyword in Modelica, it would make more sense to allow it to be shadowed, just like the other built-in things like sin and StateSelect.

Speaking of which, I assume this is valid:

model ShadowingStateSelect
  type StateSelect = enumeration(one, two);
  StateSelect s = StateSelect.one;
  Real x(stateSelect = .StateSelect.never) = time;
//Real x(stateSelect = StateSelect.never) = time; /* Error: Shadowing StateSelect doesn't have 'never'. */
end ShadowingStateSelect;

[HansOlsson]

Proposal: The names Real, Integer, Boolean and String are reserved such that it is illegal to declare an element or an enumeration literal with these names

[HansOlsson]

Should be simple - either accept or not

[henrikt-ma]

Better to present three alternatives:

1. No change
2. Make keywords
3. Add restrictions equivalent to being keywords

[HansOlsson]

The main reasons I see for having restrictions equivalent to them being keywords without making them keywords is that we avoid updating the grammar and we emphasize that they are treated uniformly with other types.

[HansOlsson]

See? I told you fixing the grammar would be easy. :)

Looking a bit more, I don't see that it would be enough to change that. (And we should clearly not copy the C/C++-grammar, it's a mess for this due to "long int" etc.)

[HansOlsson]

Phone meeting

1. No change:
2. Make keywords: Henrik, Quentin 3. Add restrictions equivalent to being keywords (only enumeration literal missing - say that similar to keywords): Hans, Elena, Gerd, Markus, Luigi Abstain: Ben, Martin