>> On 22/01/2024 21:34, Lawrence D'Oliveiro wrote:
>>> On Mon, 22 Jan 2024 09:30:21 +0100, David Brown wrote:
>>>
>>>> ... I don't use the matching names in C++ either ...
>>>
>>> I do, if/when I do use C++ and C. Don’t you think it improves readability:
>>
>> No. But I fully appreciate that this is personal preference and habit.
>
> I believe that some of the identifiers improves readability for people
> coming from a programming language which uses those English words for
> very similar operators rather than && and ||.
>
> In a green field programming language design, it's probably better
> to design that way from the start. It's a nice bonus if a language
> looks readable to newcomers.
>
Agreed.
> Generations of C coders are used to && and || though; that's the normal
> way to write C. Using these aliases is a vanishingly rare practice. An
> important aspect of readability is writing code like everyone else. When
> a language is newly designed so that there isn't anyone else, that
> doesn't have to be considered.
>
Agreed. (Although people coming to your new language probably have
experience with some other languages, and you'll want to avoid being
confusingly different from common existing languages. Choosing "&&" and
"&" for "bitwise and" and "logical and" would be a bad idea for a new
language, even if it arguably makes more sense based on the prevalence
of these operator usages.)
> For that reason, these identifiers should not be used, except for
> machine-encoding of programs into a 6 bit character set.
>
> Additionally certain names in the iso646.h header are poorly considered,
> and obstruct readability. They use the _eq suffix for an operation that
> is assignment.
>
> #define and_eq &=
>
> If the purpose of this header were to optimize readability for those
> unfamiliar with C, this should be called
>
> #define and_set &=
>
> or similar.
Or "bitmask" ?
>
> The assignment operator = should not be read "equals", but "becomes" or
> "takes the value" or "is assigned" or "is set to". This should be taken
> into consideration when coming up with word-like token or token fragment
> to represent it.
Yes.
>
> Also note the following inconsistency:
>
> #define and &&
> #define bitand &
> #define and_eq &= // what happened to "bit"?
>
> This looks like and_eq should correspond to &&=, since and is &&,
> and bitand is &. &= wants to be bitand_eq.
>
> Clearly, the purpose of this header is to allow C to be written with the
> ISO 646 character set. The choices of identifiers do not look like
> evidence of readability having been highly prioritized.
>
They are still better than trigraphs :-)