Clarifications in Section 3.7 and 5.6.1 regarding "builtin classes"

[casella]

Section 3.7 is entitled "Built-in Intrinsic Operators with Function Syntax", but it actually describes both built-in operators and built-in functions, so the title could probably be made more accurate as "Built-in Functions and Intrinsic Operators with Function Syntax".

Section 5.6.1.1 contains the following statement:

The builtin classes are put into the unnamed root of the class tree.

I would first of all suggest to use the same spelling "built-in" of Section 3.7, so you can get to this section immediately when looking for the "built-in" string in the PDF document.

Besides that, I understand from Section 4.6 that there are specialized classes:

record, type, model, block, package, function and connector

so it is clear that built-in functions are a sub-set of built-in classes, and therefore the look-up rules of 5.6.1.1 apply to them. It is a bit less clear to me that built-in intrinsic operators with function syntax are also a subset of "builtin classes". In fact, I'm not even sure they belong there; are operators classes? Probably not.

So, I would recommend to clarify the statement in 5.6.1.1 by writing it as

The built-in classes and intrinsic operators with function syntax are put into the unnamed root of the class tree.

[casella]

Of course builtin should be spelled built-in also in Section 5.6.1.2

[perost]

3.7 also seems to mix the terms operator and function arbitrarily, for example:

Note that when the specification references a function having the name of a built-in function it references the built-in function, not a user-defined function having the same name, see also section 12.5. With exception of the built-in String operator, all operators in this section can only be called with positional arguments.

I would assume both of these sentences should apply to both operators and functions. And also in 3.7.1:

whereas the event-triggering mathematical functions are described in section 3.7.2.

3.7.2 only defines operators.

I'm not sure if it's really that useful to make a distinction between functions and operators with function syntax in the first place, it seems rather arbitrary.

[henrikt-ma]

I'm not sure if it's really that useful to make a distinction between functions and operators with function syntax in the first place, it seems rather arbitrary.

In my mind, there is an important difference: Functions behave as functions, whereas (built-in) operators generally have semantics which cannot be expressed in terms of a function call (because then I would have expected it to be presented as a built-in function, not an operator). I was hoping that the Modelica specification was aiming for this kind of distinction…

[perost]

I'm not sure if it's really that useful to make a distinction between functions and operators with function syntax in the first place, it seems rather arbitrary.

In my mind, there is an important difference: Functions behave as functions, whereas (built-in) operators generally have semantics which cannot be expressed in terms of a function call (because then I would have expected it to be presented as a built-in function, not an operator). I was hoping that the Modelica specification was aiming for this kind of distinction…

3.7 begins with:

Certain built-in operators of Modelica have the same syntax as a function call. However, they do not behave as a mathematical function, because the result depends not only on the input arguments but also on the status of the simulation.

However, the very next sentence says:

There are also built-in functions that depend only on the input argument, but also may trigger events in addition to returning a value.

However, all of these "functions" are actually defined as operators, so it's all a bit confused right off the start. And many of the operators don't fit this description anyway.

[HansOlsson]

Whether it should be spelt built-in or builtin is something we can discuss; and then apply consistently.

As for separating between built-in functions and operators with function syntax it is somewhat complicated:

One could say that as long as it is a built-in operator with function syntax it doesn't matter that it could currently be described as a function, as long as that is not done. Additionally, whether it could be described as a function has in many cases changed over time, so by being clearer we risk introducing errors

Concretely consider:

• https://specification.modelica.org/master/operators-and-expressions.html#numeric-functions-and-conversion-functions They can be described as functions (currently; originally abs and sign couldn't)
• https://specification.modelica.org/master/operators-and-expressions.html#event-triggering-mathematical-functions Can after addition of GenerateEvents likely be described as functions.
• https://specification.modelica.org/master/operators-and-expressions.html#built-in-mathematical-functions-and-external-built-in-functions are just functions
• https://specification.modelica.org/master/operators-and-expressions.html#derivative-and-special-purpose-operators-with-function-syntax are operators, not functions
• https://specification.modelica.org/master/operators-and-expressions.html#event-related-operators-with-function-syntax are operators not functions

So, the ones described as operators have headings using the word "operators" and the ones that are functions have "function" in their heading.

[HansOlsson]

After looking a bit more there was one additional issue:

• rem, div, mod are sort of overloaded (so that integer operands give integer results - in addition to the event-generation). That is currently not possible in Modelica with one function; but requires two separate functions.

[casella]

My main concern when opening this ticket was about consistency. The MLS has been written over the years by many different persons and groups and some parts were later rewritten completely, e.g. the flattening part. Fixing all the logical dependencies is non-trivial, so there can be minor inconsistencies here and there.

I would suggest to first fix the current test so that it is consistent (e.g. same spelling of built-in everywhere, title reflecting the actual content of a section), without actually changing the content. That should be easy.

The discussion about actual changes of the specification (e.g. better defining what are operators and what are functions, or whatever) will probably take more time and debates, but can be done later.