How many people know about this? It was introduced in c99. If you
“#include <iso646.h>”, then you can use alternative symbols like “not”
instead of “!”, “and” instead of “&&” and “or” instead of “||”.

C++ already had this, without the need to include such a file.

On Mon, 22 Jan 2024 01:51:48 +0000, Lawrence D'Oliveiro wrote:

> How many people know about this? It was introduced in c99.

It was added in a 1995 amendment to the C90 standard.

> If you
> “#include <iso646.h>”, then you can use alternative symbols like “not”
> instead of “!”, “and” instead of “&&” and “or” instead of “||”.
>
> C++ already had this, without the need to include such a file.

Yah, so?

--
Lew Pitcher
"In Skills We Trust"

On 1/21/24 20:51, Lawrence D'Oliveiro wrote:
> How many people know about this? It was introduced in c99. If you
> “#include <iso646.h>”, then you can use alternative symbols like “not”
> instead of “!”, “and” instead of “&&” and “or” instead of “||”.

I did, and so did a lot of other people. Google groups lists 222
messages containing <iso646.h>.

> C++ already had this, without the need to include such a file.

That's because backwards compatibility with older versions of C is a
lower priority for C++ than it is for C. Existing code that ysed those
words as identifiers would break if that feature were simply always
enabled. Putting it in a standard header allows it to be under user
control.

On Sun, 21 Jan 2024 21:48:36 -0500, James Kuyper wrote:

> On 1/21/24 20:51, Lawrence D'Oliveiro wrote:
>
>> C++ already had this, without the need to include such a file.
>
> That's because backwards compatibility with older versions of C is a
> lower priority for C++ than it is for C.

I don’t think even many C++ programmers know about this.

On 22/01/2024 02:51, Lawrence D'Oliveiro wrote:
> How many people know about this? It was introduced in c99. If you
> “#include <iso646.h>”, then you can use alternative symbols like “not”
> instead of “!”, “and” instead of “&&” and “or” instead of “||”.
>
> C++ already had this, without the need to include such a file.

I can't say how many people know about it, but I certainly did. I have
not used it - and I don't use the matching names in C++ either, but I
knew about them. (I know lots more features of C and C++ than I use - I
expect that applies to most programmers.)

David Brown <david.brown@hesbynett.no> writes:
>On 22/01/2024 02:51, Lawrence D'Oliveiro wrote:
>> How many people know about this? It was introduced in c99. If you

Although it was available before 1999 - the SVR4 C compilation System
(CCS) had an iso656.h header file in the early 90's.

#ifndef _ISO646_H
#define _ISO646_H
#ident "@(#)sgs-head:common/head/iso646.h 1.2"

#define and &&
#define and_eq &=
#define bitand &

#define or ||
#define or_eq |=
#define bitor |

#define xor ^
#define xor_eq ^=

#define compl ~

#define not !
#define not_eq !=

#endif /*_ISO646_H*/
~

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:

if (ThisCh < '0' or ThisCh > '9')
{
if (AllowSign and Index == 0 and (ThisCh == '+' or ThisCh == '-'))
{
/* fine */
}
else if (AllowDecimal and not DecimalSeen and ThisCh == '.')
{
DecimalSeen = true; /* only allow one decimal point */
}
else
{
Valid = false;
break;
} /*if*/
} /*if*/

...

if
(
TheEntry->d_name[0] == '.'
and
(
TheEntry->d_name[1] == 0
or
TheEntry->d_name[1] == '.'
and
TheEntry->d_name[2] == 0
)
)
{
/* skip "." and ".." entries */
}

...

if
(
ThisCh >= 'a' and ThisCh <= 'z'
or
ThisCh >= 'A' and ThisCh <= 'Z'
or
ThisCh >= '0' and ThisCh <= '9'
or
ThisCh == '_'
or
ThisCh == '-'
or
ThisCh == '.'
or
ThisCh == '/'
)
{
Result.append(1, ThisCh);
}

On Mon, 22 Jan 2024 16:24:36 GMT, Scott Lurndal wrote:

> Although it was available before 1999 - the SVR4 C compilation System
> (CCS) had an iso6[4]6.h header file in the early 90's.

By the way, why is it called “iso646.h”?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 22 Jan 2024 16:24:36 GMT, Scott Lurndal wrote:
>> Although it was available before 1999 - the SVR4 C compilation System
>> (CCS) had an iso6[4]6.h header file in the early 90's.
>
> By the way, why is it called “iso646.h”?

ISO 646 is the ISO standard for the ASCII 7-bit character set. The
header's original intent was to make C programming easier on systems
that don't support all ASCII characters, either because they use EBCDIC
or because they use 7-bit character sets that replace some puncutation
characters with, for example, accented letters.

As for "and" being more readable than "&&", that's not necessarily the
case for people who are accustomed to reading C code.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-01-22, Lawrence D'Oliveiro <ldo@nz.invalid> 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:

Only for someone who has no experience in C or C++, and is unfamiliar
with the regular operators, and speaks English.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Mon, 22 Jan 2024 13:22:41 -0800, Keith Thompson wrote:

> As for "and" being more readable than "&&", that's not necessarily the
> case for people who are accustomed to reading C code.

You mean, “old-style C code”.

I imagine the introduction of ANSI-style argument declarations, as opposed
to the old K&R style, was a bit of a jar, too. But we got over it.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 22 Jan 2024 13:22:41 -0800, Keith Thompson wrote:
>> As for "and" being more readable than "&&", that's not necessarily the
>> case for people who are accustomed to reading C code.
>
> You mean, “old-style C code”.

No, I mean C code.

> I imagine the introduction of ANSI-style argument declarations, as opposed
> to the old K&R style, was a bit of a jar, too. But we got over it.

As far as I can tell, the macros defined in <iso646.h> have never caught
on significantly. Code using the "and" and "or" macros isn't new-style;
it's just (likely to be seen as) peculiar.

I don't think I'd have any trouble reading code that uses the macros --
but the fact that I've never had a chance to find out is telling.

If you find them more readable, that's fine, but I think that most C
programmers with any reasonable amount of experience are more likely to
find them slightly jarring.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Lawrence D'Oliveiro wrote:

> Don’t you think it improves readability:

No.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Cenunfly!

On Mon, 22 Jan 2024 23:08:53 -0000 (UTC), Blue-Maned_Hawk wrote:

> Lawrence D'Oliveiro wrote:
>
>> Don’t you think it improves readability:
>
> No.

Lessig’s Law: The one who writes the code makes the rules.

On Mon, 22 Jan 2024 14:56:53 -0800, Keith Thompson wrote:

> As far as I can tell, the macros defined in <iso646.h> have never caught
> on significantly.

The nice thing is, I don’t have to care. They have to be part of any
standards-compliant C compiler, therefore I am free to use them. And I do.

On 2024-01-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 22 Jan 2024 14:56:53 -0800, Keith Thompson wrote:
>
>> As far as I can tell, the macros defined in <iso646.h> have never caught
>> on significantly.
>
> The nice thing is, I don’t have to care. They have to be part of any
> standards-compliant C compiler, therefore I am free to use them. And I do.

Indentation not being required is part of any conforming C compiler.
Therefore, I take advantage of it by starting each line of code without
any leading whitespace, regardless of the nesting level. My coworkers
love me!

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-22, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 22 Jan 2024 23:08:53 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> Don’t you think it improves readability:
>>
>> No.
>
> Lessig’s Law: The one who writes the code makes the rules.

Accordingly, if you get to rewrite the genetic code
of someone reading the code, you may be able to dictate
what they find readable.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

[.. using ISO646 names for logical operators ..]

> I do, if/when I do use C++ and C. Don't you think it improves
> readability:
>
> [example]

No, quite the contrary.

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:
> [...]

I'm a big proponent of readable code. Most of the early languages that
I used had such keywords (and also 'begin' etc. instead of braces).

I seem to recall that the (one?) reason to not have them was to reduce
the number of literal alphabetic keywords, to avoid name clashes.

But replacing '&&' by 'and' also doesn't add to the comprehensibility
of the source code (YMMV), presuming that we want the code to be read
by people who know how to program. It's also idiomatic. And in other
contexts (than C) these symbols have similar meanings.

There's also problems with these names. For example '&&' has not the
semantics of 'and' but of 'and_then', 'or' is actually 'or_else'. Even
it that gets "fixed", it's also not addressing other punctuation token
issues, like using '==' instead of the common '=' or 'equals_to'.

Since the beginning of C we had also other inherent issues with these
symbols; not simple lexical ones like 'and', but e.g. the operator
precedence that is (IMO) broken in at least one place. (I guess you
know them.) And in the earlier C days we had not even a true boolean
type or the 'true' and 'false' literals. Fixing things in a language
like C appears to me to be an arduous and unrewarding task.

So I take it as it comes, and I think, in C, we'd need other things
than an iso646.h header or disputes about personal token preferences.
Anyway.

Janis

On 23.01.2024 00:37, Lawrence D'Oliveiro wrote:
> On Mon, 22 Jan 2024 23:08:53 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> Don’t you think it improves readability:
>>
>> No.
>
> Lessig’s Law: The one who writes the code makes the rules.

If by "The one" you mean the company and the project leader then
you are right. If you mean the individual programmer you are not
necessarily right; in my professional contexts there where even
[coding] standards defined that you had to follow. What people
make in their private cubbyhole is of course their own business
(and no one cares).

Janis

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.
The same applies to brace style, and the use of parenthesis, and
variable naming :

if ((ch < '0') || (ch > '0')) {
if (allow_sign && (i == 0) && ((ch == '+') || (ch == '-'))) {
// All fine
} else if (allow_dec && !seen_dec && (ch == '.')) {
seen_dec = true;
} else {
valid = false;
break;
}
}

I wouldn't object to seeing "and" and "or", but I would not feel it
improves readability - it would make the code look more like Python than C.

>
> if (ThisCh < '0' or ThisCh > '9')
> {
> if (AllowSign and Index == 0 and (ThisCh == '+' or ThisCh == '-'))
> {
> /* fine */
> }
> else if (AllowDecimal and not DecimalSeen and ThisCh == '.')
> {
> DecimalSeen = true; /* only allow one decimal point */
> }
> else
> {
> Valid = false;
> break;
> } /*if*/
> } /*if*/
>

On 22/01/2024 20: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:
>
> if (ThisCh < '0' or ThisCh > '9')
> {
> if (AllowSign and Index == 0 and (ThisCh == '+' or ThisCh == '-'))
> {
> /* fine */
> }
> else if (AllowDecimal and not DecimalSeen and ThisCh == '.')
> {
> DecimalSeen = true; /* only allow one decimal point */
> }
> else
> {
> Valid = false;
> break;
> } /*if*/
> } /*if*/
>

I strongly dislike C syntax, but this iso646 thing barely address 1% of
it. So I'm not surprised few bother.

Especially if you have to go the the trouble of including a header file
just to be able to use what should be language keywords.

In my everyday language (lower level like C) this can be written as:

if ch not in '0'..'9' then
if allowsign and index = 0 and ch in ['+', '-'] then
# fine

elsif allowdecimal and not decimalseen and ch = '-' then
decimalseen := true

else
valid := false
exit

end if
end if

(Notice no braces or parentheses.)

> if
> (
> ThisCh >= 'a' and ThisCh <= 'z'
> or
> ThisCh >= 'A' and ThisCh <= 'Z'
> or
> ThisCh >= '0' and ThisCh <= '9'
> or
> ThisCh == '_'
> or
> ThisCh == '-'
> or
> ThisCh == '.'
> or
> ThisCh == '/'
> )
> {
> Result.append(1, ThisCh);
> }

This one could be a Switch (mine allows 'a'..'z' like using gcc's
extension), but that might be overkill.

Otherwise:

if ch in 'A'..'Z' or ch in 'a'..'z' or ch in '0'..'9' or
ch in ['_', '-', '.', '/'] then
result.append(1, ch)

I shortened your ThisCh to something more apt for a local variable.

Alternatively, I'd use:

if namemap[ch] then
...

but this is now rewriting your code, not just showing alternate synax.

On 22/01/2024 20: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:
>
It breaks the rule that, in C, variables and functions are alphnumeric,
whilst operators are symbols. sizeof is an exception, but a justified
one. However it's harder to justify a symbol for "plus" but a word for "or".

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Tue, 23 Jan 2024 16:32:09 +0000, Malcolm McLean wrote:

> On 22/01/2024 20: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:
>>
> It breaks the rule that, in C, variables and functions are alphnumeric,
> whilst operators are symbols. sizeof is an exception, but a justified
> one. However it's harder to justify a symbol for "plus" but a word for "or".

Less importantly, it also violates the convention that C macros are named in
upper case to distinguish them from keywords and "regular" identifiers.

I'll stick with the native C operators, but IF I were working in an environment
where 'special characters' were problematic (such as where digraphs or trigraphs
are necessary), I'd rather use
a OR b
instead of
a or b

--
Lew Pitcher
"In Skills We Trust"

On 23/01/2024 16:32, Malcolm McLean wrote:
> On 22/01/2024 20: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:
>>
> It breaks the rule that, in C, variables and functions are alphnumeric,
> whilst operators are symbols. sizeof is an exception, but a justified
> one. However it's harder to justify a symbol for "plus" but a word for
> "or".

But it's OK to justify 'pow' for exponentiation?

Every explanation for && and || for every language that copied them from
C, is that && means AND, and || means OR.

Presumably everyone knows what AND and OR mean. So why not just use AND
and OR?

A lot of C code already looks a sea of punctuation; it can be good to
break it up a little.