Potential inconsistencies between the CRML specification and examples

[folmate]

Hi @audrey-jardin,

I have been going through the specification with LLMs and see what they can do with it, and some examples seem to cause issues in generated models.

In 4.13.2, Example 6, 7, and 8 fails as the parameter types are also in brackets, not just the return type. Is this an error, or I'm missing something?

In 4.6.1, Example 2, Integer x10 is E3; // No digit before the decimal exponent is marked as incorrect, but it is technically correct, as E3 can be (and is) interpreted as a variable.

In 4.21.2, partial type Quantity also fails, but this seems to be an issue with the parser. Can you confirm that the following model should parse or not?

model TestModel is {
    partial type Quantity is (Real q is rate*u + offset)  {  
        String SIUnit; // SI unit for quantity q 
        String userUnit; // User unit for quantity q 
        Real u; // Quantity q expressed in user units 
        Real rate; // Conversion rate between user units and SI units 
        Real offset; // offset between user units and SI units 
    }; 
    //Quantity x = Quantity (SIUnit = "Pa", userUnit = "bar", rate = 1.e5, offset = 0, u = 3); 
}

Thank you.

[audrey-jardin]

Hi @folmate ,

In 4.13.2, Example 6, 7, and 8, the fact that some types are in brackets is correct. This is related to the syntax used for declaring a custom operator. Brackets to the left of the "=" sign specify the input types of the operator; the information to the right of the "=" sign specifies the semantics, the calculation operations performed by the operator. Is that clearer?

In 4.6.1, Example 2, Integer x10 is E3; // No digit before the decimal exponent is marked as incorrect -> Yes I confirm since 'E' is defined as a built-in keyword for defining a decimal exponent (see paragraph 4.2.3). That being said...I'm not sure the CRML2Modelica compiler supports that. @lenaRB : do you confirm?

In 4.21.2, for the partial type Quantity example, You should discuss with @lenaRB as I'm indeed not sure that partial models are currently supported by the parser. This was not a top priority until now and we have already identified that some work should be done to enhance that part -> see ticket #9

[folmate]

Thank you for the response.

For the operator, the reason why I'm confused is that the specification says that Operators always return a value whose type is declared between square brackets. Therefore, in expression Operator [ T ] w1 T1 e1 w2 T2 e2 … wn Tn en = value; the type of value is T, but in the examples the input parameters are also in brackets.

Say, Operator count = Operator [ Integer ] count [ Boolean ] b inside [ Period ] P = card (subClock (new Clock b, P));, I understand that Integer should be in brackets, but the Boolean and Period are input parameters, and therefore those shouldn't be.

Regarding the exponent, the question is more towards if it should be accepted by the parser, or should the parser reject it, even if there is a consistent interpretation. Currently the parser accepts it as a variable, which I think is good, but then the specification should clarify, that this is only incorrect for a constructor call, but syntactically correct with a different interpretation. (My concern here is why should some variables have different restrictions on how those can be used.)

[audrey-jardin]

For the operator, my bad: you're right. Brackets of input parameters should indeed be removed.
I have just fixed that in the specification Word document (@lenaRB should share - or already have shared- it with you via sharepoint soon).

For the exponent, I don't have a strong opinion and tend to agree with your advice. It's certainly awkward to declare "e" and "E" as reserved keywords...we should discuss this further with @lenaRB , but we can modify the CRML specifications in this direction if it's more consistent/robust from a compilation standpoint...for example, by following what's done for the Modelica language (if my understanding is correct this seems to corresponds to the behavior you're proposing).