MCP-0015: Language Version #1726
Comments
modelica-trac-importer
added
enhancement
|
Comment by otter on 9 Jun 2015 08:22 UTC If several tools support these language elements, this could be marked by a comma separated list: |
|
Comment by mtiller on 9 Jun 2015 13:40 UTC
I don't like this approach. This comment line is not meant to be an alternative annotation mechanism. It seems very strange to me that we should standardize a way to indicate that the language used is non-standard. |
|
Modified by dietmarw on 9 Jun 2015 13:45 UTC |
|
Comment by hansolsson on 9 Jun 2015 13:46 UTC |
|
Modified by dietmarw on 9 Jun 2015 14:50 UTC |
1 similar comment
|
Modified by dietmarw on 9 Jun 2015 14:50 UTC |
|
Comment by hansolsson on 24 Sep 2015 09:08 UTC Reasons for separate file:
Reasons for having it as a comment:
Some other issues:
|
|
Comment by hansolsson on 24 Sep 2015 09:33 UTC
Seems unclear how to do it - but people want the functionality. |
|
Comment by hansolsson on 15 Dec 2015 09:12 UTC One discussion is whether it is a cache of meta-data, or the actual meta-data. (The cache is used for NOT reading the package, once you read the package you can verify it.) |
|
Comment by hansolsson on 15 Dec 2015 09:22 UTC |
|
Comment by hansolsson on 15 Dec 2015 09:50 UTC To allow "3.3 Revision 1" (with spaces) we need to change the regex in one of the following ways:
Possibilities: We will not spend too much on that - just want to ensure that it can be recognized by tools. Another option would be just "MCP0015", but not allowed by regex - and seems better to specify base version "3.3". |
|
Comment by hansolsson on 15 Dec 2015 09:57 UTC
|
|
Comment by hansolsson on 15 Dec 2015 10:01 UTC 3.3Revision1 Favor: 2 Unclear what polled on (regex syntax vs. how to store the specific specification version "3.3 Revision 1"), but 3.3.1 and 3.3r1 were most favored |
|
Comment by hansolsson on 13 Sep 2016 09:05 UTC Require 3.3.0 or allow 3.3? Possible regular expression: Who to update MCP? Ask original authors - otherwise we might find a volunteer. |
|
Comment by hansolsson on 3 Nov 2016 13:22 UTC Language version specified using comment at the beginning of each mo-file. |
|
Comment by hansolsson on 5 Dec 2016 14:41 UTC For using libraries we have #1023 proposing multiple uses-annotation to say that a library is compatible with e.g. both MSL 3.2 and 3.3. If the tool only has one of them this is useful to avoid problems for version-mismatch. We don't have to solve it now, but there seems to be a risk that a future solution would be incompatible. |
|
Comment by cbuerger on 5 Dec 2016 16:43 UTC
I would go a bit further and say: "It seems strange to me to tell a tool what I expect, although I do not know what I am exactly going to use until the tool starts working with me." The question are, (1) what should that very tool do if it does not support that version and (2) the other way around, which new information did the tool gather by knowing that its supposed to work with a Modelica model (as discussed later this is a non-trivial question on its own)?
So what is the version number supposed to help with? |
|
Comment by pharman on 5 Dec 2016 17:01 UTC
This is true, but #1023 also has to deal with changes in libraries involving conversion scripts. With the language version our initial assumption was that we were specifying the minimum language version required to be supported by the tool. Replying to [comment:14 hansolsson]:
I shall update this if it hasn't already been done. |
|
Comment by pharman on 5 Dec 2016 17:11 UTC
So that a tool can give correct diagnostics on encountering a model written for a newer version of the language than it supports. It doesn't change the fact that a model may or may not be supported, but gives information that is currently missing. |
|
Comment by sjoelund.se on 6 Dec 2016 06:38 UTC
Parsing is what usually causes the most severe incompatibilities for the tool, and it is something shown by the language version. For example,
|
|
Comment by hansolsson on 6 Dec 2016 09:29 UTC
I can understand that - but after analysis I don't believe the assumption is correct. Replying to [comment:20 sjoelund.se]:
And if it had been "impure function foo" it would be legal 3.3, but not 3.2.
This example indicates both that
However, I am not convinced that parsing is the most severe incompatibility. It's clearly a very visible incompatibility - whereas the different rules for optimizing pure function (see other topic) - or different starting-conditions for when-clauses (in Modelica 1.4 and earlier) are much harder to detect - and I would argue that such issues are far worse. Consider the similar case for models: if the parameter "R" for a resistor was renamed to "C" it would be a highly visible incompatibility (modifier for something missing) - but if the resistor-model switched equations to capacitance - while keeping the parameter "R" it would not as visible - but in my book, more severe. |
|
Comment by cbuerger on 6 Dec 2016 10:12 UTC Consider all use-cases we are facing. We have a model m for some standard version, a standard s and a tool t implementing s (just assume the implementation of t is standard conform so we can just think about all versioning cases of m and t). Let's go through the cases (m < t means m is for an older standard than t implements):
Also note, that only an exact version match will not pop-up a warning; the assumption that a higher version tool must support lower version models is not correct! Modelica 3.4 does not support MSL 2.x. This pushes the burden on library developers to add with every new standard another version tag to their library. To test models with a new tooling should anyway always be done. |
|
Comment by pharman on 6 Dec 2016 11:18 UTC What is not acceptable is that a model fails with a runtime error and the tool gives no possible reason or even worse gives a reason that isn't actually related to the cause. This is especially true when a simple reason exists that the tool could have diagnosed. The original motivation for this idea was that the tool I was responsible for did not support the synchronous elements added in version 3.3 of the language specification. On translating a model containing such elements, the result the user would see would be that it could not find a type called Had we had information in the model on the required language version (3.3), we could choose to either reject the model immediately, or on the model failing we would have the information to give to the user that a possible cause of failure was that it required language features we didn't support. I shall enhance the proposal with some recent use-cases and possible workflows for usage by tools. |
|
Comment by cbuerger on 6 Dec 2016 12:49 UTC
You mean simulation previously worked and with a new tooling simulation doesn't? This should never happen; any change of the standard should satisfy this (and does so far).
In my opinion, this are pretty good error messages. They point out what is broken/missing. After switching tooling, is it really necessary to warn things may be broken now? In particular at the price of many, many false positive warnings. The only use case I see is, when you try a model for the first time with some tool and it doesn't work. It might not work for many reasons though. To know, that it is not working because the model was intended for another standard version than your tooling is nice, but this warning has to outweigh its false positives. It is not obvious to me that the useful cases outweigh the false positives or that it is easy for tool vendors to filter the cases such a warning makes sense. To filter false positives requires to catch the differences between standards and that is actually half the way to just support them in the first place. |
|
Comment by pharman on 6 Dec 2016 13:29 UTC
I don't mean that with the same tool it stops working, but that if you transfer a model from a tool which supports 3.3 to one that supports 3.2 (or 3.4 to 3.3) it might not work. This isn't obvious, we promote Modelica as an open-standard and yet models aren't always exchangeable. Prior to 3.3, the version number of the MSL was sufficient to know this, but the Modelica_Synchronous library uses language version 3.3 and MSL 3.2.2, hence the problem.
Should I contact the users that raised them and tell them that they should have figured it out for themselves rather than raising a support request?
It isn't obvious to you because they aren't causing you a problem, and equally the fact that we implemented this in an existing tool would suggest we have tested the feasibility of the idea. Have you actually read the MCP? Perhaps you should attend the relevant design meeting and give some constructive viewpoints? |
|
Modified by dietmarw on 6 Dec 2016 13:40 UTC |
|
Comment by hansolsson on 14 Dec 2016 15:01 UTC
|
|
Comment by hansolsson on 21 Mar 2018 11:11 UTC |
|
Comment by henrikt on 22 Mar 2018 11:47 UTC |
|
Comment by hansolsson on 22 Mar 2018 14:30 UTC A bit long for every user-written file; especially if just writing with a text-editor - and don't want to end up with the old version that was before this feature was introduced. Note the specification text does not specify what happens if this is missing - that can be a benefit allowing the tool to interpret this in a good way (i.e. assume it is the latest version and the user just forgot it, and warn the user about missing comment). For the length there are three reasonable possibilities:
Poll for colon:
Poll for shorter:
(Updated to show that this was done after colon-poll, and since the conclusion was to drop "Modelica-Language" the colon also automatically disappeared.) Should tools modify it to latest version, or keep previous setting? Conclusion is to not specify this, since it depends on the complexity of the tool. |
|
Comment by henrikt on 23 Mar 2018 07:18 UTC |
|
Comment by henrikt on 27 Apr 2018 05:55 UTC Related comments:
|
|
Modified by henrikt on 27 Apr 2018 05:56 UTC |
modelica-trac-importer
modified the milestones:
MCP-1-InDevelopment,
MCP-2-UnderEvaluation
Modified by dietmarw on 9 Jun 2015 14:50 UTC
This is the ticket for "MPC-0015: Language Version":
During a recent design meeting, the topic of semantic version numbers was discussed. A proposal was discussed to leverage the notions of compatibility from the semantic version specification. However, it was recognized that if we did this, it would then be important for tools to know that these notions of compatibility were in effect. Initially, there was a discussion of adding a special annotation to indicate that semantic versions were being used. But it was recognized that if the tool knew what version of the language applied to the library, then this would be a more general solution since it could address other questions about language syntax and semantics.
Much of this was discussed in Ticket #643. This MCP is an attempt to generate a concrete proposal around the ideas discussed in that ticket.
Document location
Modified by dietmarw on 9 Jun 2015 13:45 UTC
This is the ticket for "MPC-0015: Language Version":
During a recent design meeting, the topic of semantic version numbers was discussed. A proposal was discussed to leverage the notions of compatibility from the semantic version specification. However, it was recognized that if we did this, it would then be important for tools to know that these notions of compatibility were in effect. Initially, there was a discussion of adding a special annotation to indicate that semantic versions were being used. But it was recognized that if the tool knew what version of the language applied to the library, then this would be a more general solution since it could address other questions about language syntax and semantics.
Much of this was discussed in Ticket #643. This MCPI is an attempt to generate a concrete proposal around the ideas discussed in that ticket.
Document location
Reported by mtiller on 9 Jun 2015 08:14 UTC
This is the ticket for "MPC-0015: Language Version":
During a recent design meeting, the topic of semantic version numbers was discussed. A proposal was discussed to leverage the notions of compatibility from the semantic version specification. However, it was recognized that if we did this, it would then be important for tools to know that these notions of compatibility were in effect. Initially, there was a discussion of adding a special annotation to indicate that semantic versions were being used. But it was recognized that if the tool knew what version of the language applied to the library, then this would be a more general solution since it could address other questions about language syntax and semantics.
Much of this was discussed in Ticket #643. This MCPI is an attempt to generate a concrete proposal around the ideas discussed in that ticket.
Migrated-From: https://trac.modelica.org/Modelica/ticket/1726
The text was updated successfully, but these errors were encountered: