Deprecate "builtin" external language #2697
Conversation
chapters/functions.tex
Outdated
| @@ -1712,14 +1712,14 @@ \section{External Function Interface}\label{external-function-interface} | |||
| This is just as for any other function. The components in the protected part allow local variables for temporary storage to be declared. | |||
| \end{nonnormative} | |||
|
|
|||
| The \lstinline!language-specification! must currently be one of \lstinline!"builtin"!, \lstinline!"C"!, \lstinline!"C..."! (for one of the specific C standards like C89, C99, and C11 -- specifying | |||
| The \lstinline!language-specification! must currently be one of \lstinline!"builtin"! (deprecated), \lstinline!"C"!, \lstinline!"C..."! (for one of the specific C standards like C89, C99, and C11 -- specifying | |||
There was a problem hiding this comment.
I only understood that we deprecated that these functions were builtin - not the entire concept of external "builtin".
There was a problem hiding this comment.
OK. If that was unclear I suggest that we ask for a clarifying poll between meetings.
To me, it seems strange to keep the concept if we don't see a use for it (which would be why it was deprecated for the current set of functions). Another reason to get rid of the unused concept is that the concept uses problematic terminology; it doesn't match my expectations at all that we would have a language without any built-in functions.
There was a problem hiding this comment.
But if you instead skip that deprecated and replace the next one by something like the following:
The \lstinline!"builtin"! specification is deprecated for the only case where it is specified: the elementary mathematical functions described in \cref{built-in-mathematical-functions-and-external-built-in-functions}.
To me that deprecation is as strong.
There was a problem hiding this comment.
It is not as strong, because only deprecating the current uses does neither allow simplification of terminology (I'd like to consider all of the functions described in the specification as "built in"), nor point in the direction of a Modelica language simplification.
However, given that there seems to have been misunderstandings regarding what we were polling on in the meeting, I still think we should do another poll – it wouldn't be right to describe "builtin" as deprecated even if I was able to convince you, as long as this is not how the poll was understood by the rest of the group.
chapters/functions.tex
Outdated
| that it relies on the C standard library of that version) or \lstinline!"FORTRAN 77"!. Unless the external language is specified, it is assumed to be \lstinline!"C"!. | ||
|
|
||
| \begin{nonnormative} | ||
| The intended use of e.g.\ C99 is to detect if the user tries to link with a C99-function using a C89 compiler. | ||
| \end{nonnormative} | ||
|
|
||
| The \lstinline!"builtin"! specification is only used for functions that are defined | ||
| The deprecated \lstinline!"builtin"! specification is only used for functions that are defined |
There was a problem hiding this comment.
I think it would be good to specify "builtin" as being a tool-specific options that does not offer portability between tools. Perhaps:
The \lstinline!"builtin"! language specification has implementation-defined results and has been deprecated in order to promote interoperability between tools.
\begin{nonnormative}
Existing code using the \lstinline!"builtin"! language specification typically mimics the built-in operator \Cref{ref-to-operators-section} with the same name and tools are recommended to continue supporting this for the time being.
\end{nonnormative}There was a problem hiding this comment.
Wouldn't that introduce a different meaning at the same time as it is deprecated? I mean, the original intention was never to have different results depending on implementation, right? I find the next sentence in the text a pretty good explanation of what it is:
The external-function call mechanism for
"builtin"functions is implementation-defined.
Also, describing it as a tool-specific option make it sound as if "builtin" is what tools are expected to use when having a tool-specific external interface. I think it makes more sense to use a non-standardized tool-specific name for the external language in this case, so that it is clear that the function is not expected to exist in other tools.
Having some non-normative text that explains a deprecated concept seems meaningful, but I don't think we should say something like this about every deprecated functionality we have:
and tools are recommended to continue supporting this for the time being
I mean, being deprecated should always be read as being required for tools to implement, but that library authors should stop using it as it is planned for removal in some future version of the specification.
There was a problem hiding this comment.
I added a reference to the section where "builtin" is used.
|
Options to choose from:
|
|
1 Daeoh, Henrik, Martin, Quentin, Stephan Go for 1. |
Fixes #2662
This combines the two decided changes:
Modelica.Mathnon-normatively."builtin"external language.With the deprecation of the
"builtin"external language, it no longer makes sense to refer to these as the built-in mathematical functions, so they were renamed the elementary mathematical functions.