Vendor Neutral Modelica Annotation Prototypes in MSL

[modelica-trac-importer]

Reported by peter.fritzson on 1 Oct 2012 15:17 UTC Regarding new annotations,

There should a neutral mechanism where vendor names do not appear in MSL. This can e.g. be used for new annotations in the prototype stage, for prototype version of the annotations.

Proposal:

Introduce something called AnnotationPrototype__AnnotationName

An annotation prototype can be introduced in MSL, provided that:

• Name and Documentation about the annotation is registered at modelica.org somewhere (or the SVN). The purpose, motivation, implementation hints.

• There should be a contact person for the Annotation Prototype proposal, and also a library officer who has done some preliminary checking of it.

As usual, annotations should not influence the simulation behavior, only tool appearance (graphical), and maybe performance.

There is a discussion if such annotation prototypes should be allowed in MSL, since the language and library standard need to become more stable in the future.

The annotation prototypes could be coupled to the innovation process. The question is whether they should be allowed in released versions of MSL or only in prototype versions of MSL? Anyway, anotation prototypes is a step forward compared to the current situation when we have vendor specific annotations with vendor names in MSL.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/849

[modelica-trac-importer]

Comment by hansolsson on 1 Oct 2012 15:38 UTC Adding my comments from mail so that the concrete proposals ideas are not lost:

Was also going to suggest something similar; but with __Prototype_…, __Proposed_… or __Experimental_… instead; so basically just viewing it as a vendor-specific annotation for the Prototype-vendor, e.g.:

  annotation(__Experimental_choicesAllMatching=true);

Alternatively starting with a lower-case letter.

As for registering I don’t see that we need a need new infrastructure. It should be a proposal (in some stage) for Modelica Language, so it should be on the trac – but it might help if we can tag them in some way.

[modelica-trac-importer]

Comment by choeger on 1 Oct 2012 17:42 UTC Just for the sake of style: Is there a reason we cannot use the existing namespace technique (the conceptual representation as records) for those annotations?

e.g.

annotation(Experimental(choicesAllMatching = true ));

For later versions, I would really like to see all annotations defined as records (as for instance in Java). A compiler could thus check for valid use of annotations. The semantics would, of course, be defined as now, but could be reflected e.g. in comments of the defining record.

If interest in this exists, I could write a more formal proposal about this.

[modelica-trac-importer]

Comment by uckun on 2 Oct 2012 14:50 UTC (discussion moved over from the Modelica-Design group)

Mike Tiller asked me to clarify my position on annotations. Here is my response.

In MSL, I am opposed to the use of any vendor-specific annotations (and I applaud the MA for taking a bold step to eliminate them from the MSL). MSL should not contain references to specific products or language features that are not covered in the official language specification.

In the production version of MSL, I am also opposed to the use of vendor-neutral annotations. MSL is one of the core capabilities included in Modelica, and it needs to be as robust as possible in order for it to be used in engineering practice. The presumed purpose of prototype annotations is to introduce new features before such features are ratified by the MA. Even if we do not allow annotations that change language semantics, there are several risks in using unofficial annotations in the MSL. If users integrate MSL models with prototype annotations in their production code, what would happen if the prototype function is revised, removed, or renamed in the future? What if the MA cannot agree on the implementation of a prototype and it lingers on as an unofficial language feature for several years? What is the tool vendors' responsibility for supporting these annotations? What is the process for preventing a large number of new half-baked annotations from flooding in?

In my opinion, the only safe use of annotations in the MSL is in "experimental" versions of the MSL.

Based on my brief experience in the Modelica community, the main issue appears to be a rather slow and arduous innovation process. To the best of my understanding, the use of annotations in the MSL is envisioned as a way for tool vendors and library providers to forge ahead with new ideas without having to wait for the MA to ratify them. This is a dangerous pattern that limits the authority of the MA as the official forum for defining the Modelica language.

I believe that a safer, more robust approach is to improve the innovation process within the MA so that people won't have to go around the ratification bottleneck.

[modelica-trac-importer]

Comment by choeger on 2 Oct 2012 16:38 UTC Replying to [comment:3 uckun]:

In my opinion, the only safe use of annotations in the MSL is in "experimental" versions of the MSL.

Did you consider all current use cases of annotations? In current Modelica, they serve a lot of different purposes: Documentation, graphical description, optimizations and execution information. They are all well founded IMO. The common principle I can see is, that you do not need an annotation to reason about the meaning of a model. This is IMO a little bit different from Java where e.g. the @Test annotation is crucial in a given context. Yet Modelica does a little bit more with annotations than e.g. Java: Java has a static void main() entry point where Modelica allows to use an annotation.

[modelica-trac-importer]

Comment by uckun on 23 Oct 2012 23:14 UTC Christoph is correct. Annotations (especially vendor-specific annotations) should not be used to modify language semantics. This is a necessary (but not sufficient) requirement for interoperability between various tools. He is also correct that not all annotations have the potential to cause interoperability problems between tools and models, which is my primary concern.

Of the 12 annotation types listed in the language spec, here are the ones I have specific concerns about:

• Annotations for the use of external functions: Perfectly reasonable in end-user models, but might cause compatibility issues if used in MSL.
• Vendor-specific annotations. The language spec is overly permissive about the use of such annotations. To quote the 3.3 spec (page 213): "A Modelica tool is free to define and use other annotations [...]. A vendor may – anywhere inside an annotation – add specific, possibly undocumented, annotations which are not intended to be interpreted by other tools." Essentially, this language allows a vendor to define annotations that perform specific functions that tools from other vendors may not be able to parse or replicate. Again, this might be OK in end-user models as long as the end user is committed to a particular tool for life, at their own risk (but not desirable from the perspective of an open language standard that promotes interoperability). When such annotations leak out to the MSL (as is the case with the current MSL), they render affected MSL models unusable in other tools.

All other annotation types are benign with respect to their use in MSL models.

I will repeat the most important point from my earlier comment. The use of vendor-specific annotations for "innovation", that is, to stay ahead of the official language specification, is a dangerous pattern that causes interoperability issues between tools and limits end-user choice. It is also contrary to the spirit of an open language specification that is managed by the Modelica community.

At the next Design Meeting, I will propose some approaches to increasing the efficiency of the innovation process so that new features may be ratified quickly and incorporated into the language spec without having to circumvent the spec through vendor-specific annotations.

[modelica-trac-importer]

Comment by otter on 11 Dec 2015 11:35 UTC Set the milestone do "undecided", because I do not understand what should be improved in MSL 3.2.2.

I like the idea of using an experimental Modelica annotation and maybe if it is necessary for some good reason we should introduce it. However, I do not see that this is the case for MSL 3.2.2