More consistently describe where an annotation is allowed - #3927
More consistently describe where an annotation is allowed#3927henrikt-ma wants to merge 2 commits into
Conversation
| This section describes annotations that a top-level class can have to specify information associated to the version number. | ||
|
|
||
| The \lstinline!versionBuild! and \lstinline!dateModified! annotations can also be specified in the \lstinline!uses! annotation (together with the version number). | ||
| Some of the annotations can also be specified in the \lstinline!uses! annotation. |
There was a problem hiding this comment.
| Some of the annotations can also be specified in the \lstinline!uses! annotation. | |
| Some of the annotations can also be specified in the \lstinline!uses! annotation, as stated below. |
Or something like that.
Compared to the previous text it seemed a bit vague (which ones?)
I understand that since it is given for the specific annotations it is better to only give it there - but make that clear for users.
| \end{lstlisting}\end{synopsis} | ||
| \begin{semantics} | ||
| A function with one output formal parameter may have one or more {\lstinline!inverse!} annotations to define inverses of this function. | ||
| Allowed for function class annotations when the function has exactly one output formal parameter. |
There was a problem hiding this comment.
A side-note: At some point we might want to generalize inverses to multiple outputs - but not now. As I understand it one issue is the syntax.
| connect( // This comment does not impact syntactic equivalence. | ||
| a[i], | ||
| b[2*i] /* Without whitespace in the indexing expression. */ ); | ||
| b[2*i] /* Without white-space in the indexing expression. */ ); |
There was a problem hiding this comment.
I was unsure if that was needed, and searched for "white-space vs whitespace" which gave:
And the CoPilot summary:
Use "whitespace" as a single word in computing contexts and "white space" as two words in typography or general design.
Usage in Computing
In programming and computer science, "whitespace" refers to characters that create blank space in text, such as spaces, tabs, and line breaks. These characters affect text layout but are not visible themselves, and the term is typically written as a single word when used attributively, for example, "whitespace character" or "remove whitespace from a string"
Standards like the HTML and CSS specifications consistently use "whitespace" to refer to these characters
(Later note: That summary wasn't fully correct, HTML talks about "whitespace", but CSS 2.1 discusses "white space" while the property is called "white-space". CSS 1 also had the property "white-space" - but discussed "whitespace". It could even be that hyphen in the property-name is to make it easier to discuss whitespace as a concept vs. the property white-space.)
Thus I think we might as well keep "whitespace".
| b[2*i] /* Without white-space in the indexing expression. */ ); | |
| b[2*i] /* Without whitespace in the indexing expression. */ ); |
| \begin{semantics} | ||
| The class annotation \lstinline!defaultComponentPrefixes! gives a whitespace separated list of recommended type prefixes to include in the \productionref{type-prefix} part of a \productionref{component-clause1} generated when creating a component of the class. | ||
| Allowed for class annotations. | ||
| Specifies a white-space separated list of recommended type prefixes to include in the \productionref{type-prefix} part of a \productionref{component-clause1} generated when creating a component of the class. |
There was a problem hiding this comment.
| Specifies a white-space separated list of recommended type prefixes to include in the \productionref{type-prefix} part of a \productionref{component-clause1} generated when creating a component of the class. | |
| Specifies a whitespace separated list of recommended type prefixes to include in the \productionref{type-prefix} part of a \productionref{component-clause1} generated when creating a component of the class. |
So, no change here either.
2 participants
This addresses most of a problem I noted when an LLM didn't dare drawing conclusions about where the
missingInnerMessageannotation is allowed.Currently not covered by this PR:
Licenseannotation (three different context, two different value types).