Date: Fri, 6 Oct 2023 14:24:07 +0300
On Fri, 6 Oct 2023 at 12:24, Jens Gustedt <jens.gustedt_at_[hidden]> wrote:
> > It wasn't obvious to me whether the concern is about the feasibility
> > of using such words or a usability matter.
> > "pre" and "post" would indeed be highly problematic to try to make
> > actual full keywords, which is why they're not.
>
> ok
>
> for C we woudn't know how to make such subtle differences for words with fixed meaning in the grammar. So if we would do that, this would be either keywords or predefined macros (that come from a header, usually)
Well, it's rather important that words such as "pre" and "post" aren't
reserved elsewhere other than at a particular location in function
declarations. It also doesn't seem
feasible to provide such words as any sort of identifiers declared in
a standard library header, because the intent is to allow using them
as function names or variable names. If you mean something like
_Precondition/_Postcondition as predefined macros, then we're no
longer talking about using the same syntax for C and C++.
> > > > > This should be "precondition" or similar. People that argue that this is too long, should review the capacities of their IDE.
> > > > Why?
> > > because this also speaks to people who discover this on the fly. I know that there is a tendency to use obfuscation in our communities to show off, but we could perhaps keep it on a level that is quickly Comprensible ton people coming from other languages, for example.
> >
> > Understood, but these are just abbreviations, not quite obfuscations,
> > and once learned, which doesn't seem to take a long time,
> > it ends up being an advantage that they're not as long as the full words are.
>
> That advantage is minimal compared to the problems in comprehension and language specification, I think.
I don't understand what the language specification problem is - are
you talking about what you hint at above, i.e. using a name
that is found not to clash with any existing or plausible user code,
i.e. making these actual keywords, rather than context-sensitive
grammar parts? At any rate, this isn't particularly hard to specify,
all you need is an optional contract-checking-annotation form that
appears
at the end of a declaration, and is there only for function declarations.
Our field experience, limited in scope and audience as it may be,
suggests that there's no particular comprehension problem for users of
this facility.
> > It wasn't obvious to me whether the concern is about the feasibility
> > of using such words or a usability matter.
> > "pre" and "post" would indeed be highly problematic to try to make
> > actual full keywords, which is why they're not.
>
> ok
>
> for C we woudn't know how to make such subtle differences for words with fixed meaning in the grammar. So if we would do that, this would be either keywords or predefined macros (that come from a header, usually)
Well, it's rather important that words such as "pre" and "post" aren't
reserved elsewhere other than at a particular location in function
declarations. It also doesn't seem
feasible to provide such words as any sort of identifiers declared in
a standard library header, because the intent is to allow using them
as function names or variable names. If you mean something like
_Precondition/_Postcondition as predefined macros, then we're no
longer talking about using the same syntax for C and C++.
> > > > > This should be "precondition" or similar. People that argue that this is too long, should review the capacities of their IDE.
> > > > Why?
> > > because this also speaks to people who discover this on the fly. I know that there is a tendency to use obfuscation in our communities to show off, but we could perhaps keep it on a level that is quickly Comprensible ton people coming from other languages, for example.
> >
> > Understood, but these are just abbreviations, not quite obfuscations,
> > and once learned, which doesn't seem to take a long time,
> > it ends up being an advantage that they're not as long as the full words are.
>
> That advantage is minimal compared to the problems in comprehension and language specification, I think.
I don't understand what the language specification problem is - are
you talking about what you hint at above, i.e. using a name
that is found not to clash with any existing or plausible user code,
i.e. making these actual keywords, rather than context-sensitive
grammar parts? At any rate, this isn't particularly hard to specify,
all you need is an optional contract-checking-annotation form that
appears
at the end of a declaration, and is there only for function declarations.
Our field experience, limited in scope and audience as it may be,
suggests that there's no particular comprehension problem for users of
this facility.
Received on 2023-10-06 11:24:21