Add restriction for time. #3790
Conversation
|
|
||
| All declared variables are functions of the independent variable \lstinline!time!. | ||
| The variable \lstinline!time! is a built-in variable available in all models and blocks, which is treated as an input variable. | ||
| The name \lstinline!time! is reserved and may not declared in any class. |
There was a problem hiding this comment.
I thought the plan in #1243 (comment) was to make it a keyword? That still sounds like the clean way to do it; just add it to primary in the grammar.
There was a problem hiding this comment.
Yes, that would be the alternative.
I see two minor issues:
- I'm not sure we want it syntax highlighted as a keyword in the specification.
- Describing its attributes (in particular its start-attribute - which may be useful for clocked semantics) becomes a bit messy, but by just stating that it corresponds to a variable defined as:... would likely work.
There was a problem hiding this comment.
I personally prefer that time does not look like any other identifier.
This is what we have today:
This is with time as a morekeywords=[1] (next to true and false):
Stating that time references a built-in variable defined as… sounds like a good approach to me.
henrikt-ma
left a comment
henrikt-ma
left a comment
There was a problem hiding this comment.
Whatever we do to resolve this, there needs to be some change under \cref{modelica-keywords}.
|
|
||
| In particular, it is not allowed to declare an element or enumeration literal with these names. | ||
| This also applies to the identifiers that name the predefined types \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, and \lstinline!String!, see \cref{predefined-types-and-classes}. | ||
| This also applies to the identifiers that name the predefined types \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, and \lstinline!String!, see \cref{predefined-types-and-classes}, and the variable \lstinline!time!, see \cref{built-in-variable-time}. |
There was a problem hiding this comment.
There is not the same "need" to treat time similar to Real, as there is only one trivial change needed in the grammar for time, whereas the builtin types would require a bit more. Hence, I think we should do time properly instead of expanding the non-keyword mess.
There was a problem hiding this comment.
Well, as far as I can see it was not entirely trivial - and since tool grammars are unlikely to exactly match the grammar in the specification there's a risk that something was missed.
2 participants
Closes #1243