scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> An issue with the use of the iso646 'and' macro is that the
> typical reader, unfamiliar with iso646, might assume a bitwise
> and rather than a 'logical' or 'conditional' and.

It uses "bitand" for "&", "and" for "&&". (Reasonable, IMHO, because
"&&" is more common. One might argue that when C split B's "&" operator
into bitwise and logical versions, it would have made sense to use "&"
for logical and "&&" for bitwise -- but that ship sailed *long* ago.)

Here are the symbols defined in <iso646.h> on my system; it should be
the same in any implementation.

#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=

--
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 <ldo@nz.invalid> writes:
> On Tue, 23 Jan 2024 17:21:40 -0000 (UTC), Lew Pitcher wrote:
>> Less importantly, it also violates the convention that C macros are
>> named in upper case to distinguish them from keywords and "regular"
>> identifiers.
>
> Why does C allow lowercase in macro names, then?

Because it's a convention, not a language rule.

--
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 <ldo@nz.invalid> wrote:
> On Tue, 23 Jan 2024 12:13:27 -0800, Keith Thompson wrote:
>
>> There's no hard rule that operators must be
>> punctuation, just a general trend.
>
> And iso646.h demonstrates that that trend is at an end.

In the real world, iso646.h is almost never used. I
do not claim to be any kind of programming expert but
I have read a considerable amount of C code of various
projects. I have personally witnessed that everybody
always uses "&&" and "||".

You can probably download thousands of C codebases
from github and you will find out that reality is
like that.

br,
KK

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 23 Jan 2024 12:13:27 -0800, Keith Thompson wrote:
>> There's no hard rule that operators must be
>> punctuation, just a general trend.
>
> And iso646.h demonstrates that that trend is at an end.

It does no such thing. Macro names are identifiers, and <iso646.h> only
defined macro names. Since <iso646.h> is rarely used, its existence
doesn't demonstrate any kind of trend.

The header was introduced to make it easier (or possible) to write C
code on systems/keyboards that don't support certain characters like '&'
and '|' -- similar to digraphs and trigraphs.

--
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 Tue, 23 Jan 2024 14:51:52 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Tue, 23 Jan 2024 17:21:40 -0000 (UTC), Lew Pitcher wrote:
>>
>>> Less importantly, it also violates the convention that C macros are
>>> named in upper case to distinguish them from keywords and "regular"
>>> identifiers.
>>
>> Why does C allow lowercase in macro names, then?
>
> Because it's a convention, not a language rule.

So what would one mean by “violate”, other than “I personally don’t like
it”?

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 23 Jan 2024 19:32:26 -0000 (UTC), Kalevi Kolttonen wrote:
>>
>>> Dennis Ritchie has said that he regretted the spelling of creat(2)
>>> function. Presumably the abbreviation was supposed to save one byte of
>>> storage.
>>
>> Given that, in POSIX, all the functions of creat(2) have been subsumed
>> under open(2) anyway, we can largely ignore that.
>
> I know. creat() is now completely redundant because
> open() suffices. The reason I brought it up was just
> so that people would realize that at least sometimes
> it was a matter of saving storage space - even one
> byte.

I don't believe it was ever about storage space.

Early UNIX systems used ASR-33 teletypes for interactive I/O. The
keyboard required a lot more physical force than modern keyboards do,
which made names like "mv" and "rm" easier to type than, say "rename"
and "delete". (And it's turned out that the terse names aren't much of
a problem. It would be easy to set up aliases with more verbose names,
but few if any people bother to do so.)

Some function names were limited to 6 characters by linker limitations,
but that doesn't explain "creat", which was just a poor choice.

[...]

--
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 Tue, 23 Jan 2024 22:47:30 -0000 (UTC), Kalevi Kolttonen wrote:

> What?! Are you saying that there is no way to label functions as private
> in Python? That sounds absolutely horrible. Why would anyone design a
> language with object-oriented features without support for
> encapsulation?

Because Python is not Java.

For comparison, Java’s core language reference manual is (last I checked)
around 900 pages. Python’s core language is less than a quarter of that.
And yet it manages to include features, like custom operator overloads,
that Java does not.

Python also has metaclasses. Does your favourite OO language have
metaclasses?

Python doesn’t need “final” or “private” or “protected”, because it is
after all a dynamic language. You can write functions which are class
factories and function factories.

Actually, you can achieve the effect of access restrictions that way.

On Tue, 23 Jan 2024 22:45:17 GMT, Scott Lurndal wrote:

> The header file has been around for over three decades, yet it's not in
> common (or even uncommon) use.

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

On Tue, 23 Jan 2024 15:10:36 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Tue, 23 Jan 2024 12:13:27 -0800, Keith Thompson wrote:
>>
>>> There's no hard rule that operators must be punctuation, just a
>>> general trend.
>>
>> And iso646.h demonstrates that that trend is at an end.
>
> It does no such thing.

A “trend” means ongoing developments continue to follow the same pattern.
There have been no new non-alphanumeric operators added to C in, oh, over
40 years. Therefore the “trend” actually came to an end a long time ago.

On 2024-01-23, bart <bc@freeuk.com> wrote:
>> ANSI Common Lisp uses symbols like logand, logior, logxor, ...
>> for bitwise operations.
>
> Then it is confusing. What does it use for non-bitwise logical operations?

and, or, not

--
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.

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 23 Jan 2024 19:32:26 -0000 (UTC), Kalevi Kolttonen wrote:
>>
>>> Dennis Ritchie has said that he regretted the spelling of creat(2)
>>> function. Presumably the abbreviation was supposed to save one byte of
>>> storage.
>>
>> Given that, in POSIX, all the functions of creat(2) have been subsumed
>> under open(2) anyway, we can largely ignore that.
>
>I know. creat() is now completely redundant because
>open() suffices. The reason I brought it up was just
>so that people would realize that at least sometimes
>it was a matter of saving storage space - even one
>byte.

IIRC, it was more about allowing space for a leading underscore
added during the link process.

On 23/01/2024 22:47, Kalevi Kolttonen wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 23 Jan 2024 19:32:26 -0000 (UTC), Kalevi Kolttonen wrote:
>>
>>> Dennis Ritchie has said that he regretted the spelling of creat(2)
>>> function. Presumably the abbreviation was supposed to save one byte of
>>> storage.
>>
>> Given that, in POSIX, all the functions of creat(2) have been subsumed
>> under open(2) anyway, we can largely ignore that.
>
> I know. creat() is now completely redundant because
> open() suffices. The reason I brought it up was just
> so that people would realize that at least sometimes
> it was a matter of saving storage space - even one
> byte.
>
>> There are other worse problems with C. Like its use of “=” (the
>> mathematical equality operator) for assignment, instead of using the “:=”
>> symbol that the Algols had adopted.
>
> Well I started with Microsoft BASIC on Commodore 64 39 years ago.
> So I am well used to "=" and do not consider it a problem.

I've used ":=" with Algol and "=" with Fortran (a bit longer ago).

That is not itself the problem.

The problem is allowing both assignment and equality within the same
expression, which is what C does. Algol, Fortran and BASIC didn't do that.

If that wasn't the case, then you could use "=" for both assignment, and
equality, without ambiguity.

Languages that use ":=" and "=" for those operations, fare better than C
that uses "=" and "==".

>>> But the Python designers botched at least one thing concerning that
>>> philosophy: private functions are not defined by "private" keyword like
>>> in Java but instead the designers violated their own basic principle of
>>> easy readability: the "privateness" is defined by by prefixing the
>>> function names with an underscore ("_").
>>
>> That is merely a convention, a hint that the user might want to stay away
>> from such a symbol, not a hard requirement, which is why it was designed
>> that way. As Guido van Rossum has said: “We are all consenting adults
>> here”.
>
> What?! Are you saying that there is no way to label functions as private
> in Python? That sounds absolutely horrible. Why would anyone design a
> language with object-oriented features without support for encapsulation?

Python is 'ultra-dynamic'. That's why it's so hard to make it
performant. So you can do this:

import math

math.pi = "pie"
math.sqrt = lambda x:x*x

print(math.pi*2)
print(math.sqrt(10))

Output is:

piepie
100

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 23 Jan 2024 14:51:52 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Tue, 23 Jan 2024 17:21:40 -0000 (UTC), Lew Pitcher wrote:
>>>> Less importantly, it also violates the convention that C macros are
>>>> named in upper case to distinguish them from keywords and "regular"
>>>> identifiers.
>>>
>>> Why does C allow lowercase in macro names, then?
>>
>> Because it's a convention, not a language rule.
>
> So what would one mean by “violate”, other than “I personally don’t like
> it”?

Obviously, it would mean not following the convention.

There clearly is a convention that most macro names should be defined in
all caps. Equally clearly, the standard library does not uniformly
follow that convention. I have no problem with that.

I might have some more thoughts on the matter, but I'm not sure where
you're going with this.

--
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 <ldo@nz.invalid> writes:
> On Tue, 23 Jan 2024 15:10:36 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Tue, 23 Jan 2024 12:13:27 -0800, Keith Thompson wrote:
>>>> There's no hard rule that operators must be punctuation, just a
>>>> general trend.
>>>
>>> And iso646.h demonstrates that that trend is at an end.
>>
>> It does no such thing.
>
> A “trend” means ongoing developments continue to follow the same pattern.
> There have been no new non-alphanumeric operators added to C in, oh, over
> 40 years. Therefore the “trend” actually came to an end a long time ago.

OK, "trend" was not the best word; it implies something changing over
time, which isn't really the case here. Perhaps "convention" would have
been more apt.

I believe the only thing iso646.h demonstrates is the (largely former)
need to write C on systems that do not support full ASCII. This is
fully explained in the C99 Rationale,
<http://www.open-std.org/jtc1/sc22/WG14/www/C99RationaleV5.10.pdf>;
search for "MSE.4". It says nothing about "and" being more readable
than "&&" on systems that are able to display the '&' character.

If you want to use it in your own code, nobody will stop you.

--
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 1/23/2024 3:51 PM, Scott Lurndal wrote:
> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 23 Jan 2024 19:32:26 -0000 (UTC), Kalevi Kolttonen wrote:
>>>
>>>> Dennis Ritchie has said that he regretted the spelling of creat(2)
>>>> function. Presumably the abbreviation was supposed to save one byte of
>>>> storage.
>>>
>>> Given that, in POSIX, all the functions of creat(2) have been subsumed
>>> under open(2) anyway, we can largely ignore that.
>>
>> I know. creat() is now completely redundant because
>> open() suffices. The reason I brought it up was just
>> so that people would realize that at least sometimes
>> it was a matter of saving storage space - even one
>> byte.
>
> IIRC, it was more about allowing space for a leading underscore
> added during the link process.

Actually, this rings a bell in my head about that leading underscore.
Notice the difference between:

Take this function:
____________________________
..align 16
..globl ac_i686_stack_mpmc_push_cas
ac_i686_stack_mpmc_push_cas:
movl 4(%esp), %edx
movl (%edx), %eax
movl 8(%esp), %ecx

ac_i686_stack_mpmc_push_cas_retry:
movl %eax, (%ecx)
lock cmpxchgl %ecx, (%edx)
jne ac_i686_stack_mpmc_push_cas_retry
ret
____________________________

vs this one wrt mingw over on windows:

http://web.archive.org/web/20060214112545/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_mingw_asm.html

Notice the leading underscore! Iirc, I could not get it to link
correctly using mingw.
____________________________
..align 16
..globl _ac_i686_stack_mpmc_push_cas
_ac_i686_stack_mpmc_push_cas:
movl 4(%esp), %edx
movl (%edx), %eax
movl 8(%esp), %ecx

_ac_i686_stack_mpmc_push_cas_retry:
movl %eax, (%ecx)
lock cmpxchgl %ecx, (%edx)
jne _ac_i686_stack_mpmc_push_cas_retry
ret
____________________________

On Tue, 23 Jan 2024 16:16:31 -0800, Keith Thompson wrote:

> Obviously, it would mean not following the convention.

Thumbing one’s nose at staid convention? How shocking!

On 1/23/2024 4:35 PM, Chris M. Thomasson wrote:
> On 1/23/2024 3:51 PM, Scott Lurndal wrote:
>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Tue, 23 Jan 2024 19:32:26 -0000 (UTC), Kalevi Kolttonen wrote:
>>>>
>>>>> Dennis Ritchie has said that he regretted the spelling of creat(2)
>>>>> function. Presumably the abbreviation was supposed to save one byte of
>>>>> storage.
>>>>
>>>> Given that, in POSIX, all the functions of creat(2) have been subsumed
>>>> under open(2) anyway, we can largely ignore that.
>>>
>>> I know. creat() is now completely redundant because
>>> open() suffices. The reason I brought it up was just
>>> so that people would realize that at least sometimes
>>> it was a matter of saving storage space - even one
>>> byte.
>>
>> IIRC, it was more about allowing space for a leading underscore
>> added during the link process.
>
> Actually, this rings a bell in my head about that leading underscore.
> Notice the difference between:
[...]

For some damn reason that bell toll made me think of the following song:

Ring My Bell

https://youtu.be/Dp11DjaUc5A?t=45

lol! ;^D

On Tue, 23 Jan 2024 15:35:39 -0800, Keith Thompson wrote:

> The keyboard required a lot more physical force than modern keyboards
> do, which made names like "mv" and "rm" easier to type than, say
> "rename" and "delete".

And yet it turns out the OS calls are indeed things like “rename” and
“unlink”, not “mv” or “rm”.

On 1/23/24 16:28, Scott Lurndal wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 1/23/24 13:52, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 23/01/2024 16:32, Malcolm McLean wrote:
>>>
>>>>
>>>> Every explanation for && and || for every language that copied them from
>>>> C, is that && means AND, and || means OR.
>>>
>>> in C, && specifically means 'conditional and'. The programmer can
>>> rely on the fact that the second term will not be evaluated if
>>> the first term evaluates to false.
>>
>> Actually, C uses the term "Logical AND".
>
> The term 'conditional and' has been in common use for decades.

I've never heard of it. When searching Wikipedia, "conditional and" the
first two pages of hits don't seem to contain any that are actually
relevant. A search on "logical and", on the other hand, redirects to
"logical conjunction", which does seem to be relevant, yet it makes no
reference to "conditional and" as an alternative term for the same
thing. I think that that term might not be as widely used as you think.

A Google search for "logical and" has many relevant hits. A search for
"conditional and" produces a much smaller number of hits, which suggest
that it's a term associated with C# and Java, and at least one source
described it by saying the "coditional and operator performs a ogical
and operation", which sounds rather confused to me.

On Tue, 23 Jan 2024 16:27:25 -0800, Keith Thompson wrote:

> I believe the only thing iso646.h demonstrates is the (largely former)
> need to write C on systems that do not support full ASCII.

It does seem a very late addition for a purpose which would have been a
lot more relevant decades earlier. By that point, implementations that did
not support full ASCII would have been museum pieces.

Reminds me of how PL/I added “eq”, “ne”, “lt”, ”gt”, “le”, “ge” as
alternatives to “=”, “¬=”, “<”, ”>“, “¬>”, “¬<” for use on systems which
didn’t have the requisite character set.

Incidentally, those six symbols were the only reserved words in the entire
language. You’d think they could have done it Fortran-style, without
reserved words.

> If you want to use it in your own code, nobody will stop you.

But will I continue to hear complaints from you about it?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 23 Jan 2024 16:27:25 -0800, Keith Thompson wrote:
>> I believe the only thing iso646.h demonstrates is the (largely former)
>> need to write C on systems that do not support full ASCII.
>
> It does seem a very late addition for a purpose which would have been a
> lot more relevant decades earlier. By that point, implementations that did
> not support full ASCII would have been museum pieces.

<iso646.h> was added in 1995, and it was intended to replace a number of
implementation-specific workarounds. You can learn more if you'll read
the C99 Rationale that I cited earlier.

[...]

>> If you want to use it in your own code, nobody will stop you.
>
> But will I continue to hear complaints from you about it?

I can't continue what I never started.

--
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 Tue, 23 Jan 2024 17:32:37 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> It does seem a very late addition for a purpose which would have been a
>> lot more relevant decades earlier. By that point, implementations that
>> did not support full ASCII would have been museum pieces.
>
> <iso646.h> was added in 1995, and it was intended to replace a number of
> implementation-specific workarounds.

Just in time for them to become unnecessary, I would say.

>> But will I continue to hear complaints from you about it?
>
> I can't continue what I never started.

I’ll take that as a “yes”.

On 2024-01-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 23 Jan 2024 15:35:39 -0800, Keith Thompson wrote:
>
>> The keyboard required a lot more physical force than modern keyboards
>> do, which made names like "mv" and "rm" easier to type than, say
>> "rename" and "delete".
>
> And yet it turns out the OS calls are indeed things like “rename” and
> “unlink”, not “mv” or “rm”.

Consider that the /bin/mv executable perhaps only contains as few
as just one call to the rename function.

The mv program is invoked many more times than the number of
times someone typed out the rename call in its source code.

Short keyboard sequences in the UI level are much more important
than function names in the source code.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 1/23/24 19:27, Keith Thompson wrote:
....
> I believe the only thing iso646.h demonstrates is the (largely former)
> need to write C on systems that do not support full ASCII. This is
> fully explained in the C99 Rationale,
> <http://www.open-std.org/jtc1/sc22/WG14/www/C99RationaleV5.10.pdf>;
> search for "MSE.4". It says nothing about "and" being more readable
> than "&&" on systems that are able to display the '&' character.

It does say, in lines 26-29, that "The Committee recognizes that the
solution offered in this header is incomplete and involves a mixture of
approaches, but nevertheless believes that it can help make Standard C
programs more readable." However, if you examine the context of that
statement, what it's saying is that they are more readable than is
trigraphs. In other words, they are saying that "or" is more readable
than "??!??!", which I doubt that anyone would disagree with.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/23/24 19:27, Keith Thompson wrote:
> ...
>> I believe the only thing iso646.h demonstrates is the (largely former)
>> need to write C on systems that do not support full ASCII. This is
>> fully explained in the C99 Rationale,
>> <http://www.open-std.org/jtc1/sc22/WG14/www/C99RationaleV5.10.pdf>;
>> search for "MSE.4". It says nothing about "and" being more readable
>> than "&&" on systems that are able to display the '&' character.
>
> It does say, in lines 26-29, that "The Committee recognizes that the
> solution offered in this header is incomplete and involves a mixture of
> approaches, but nevertheless believes that it can help make Standard C
> programs more readable." However, if you examine the context of that
> statement, what it's saying is that they are more readable than is
> trigraphs. In other words, they are saying that "or" is more readable
> than "??!??!", which I doubt that anyone would disagree with.

It's also more readable than, say, "Hello, world¥n", which is what
"Hello, world\n" looks like in JIS X 0201, a Japanese variant of ASCII.

Before Unicode, it was common to define 7-bit character sets that
replaced some characters with local versions such as accented letters.
I vaguely recall that some C programmers back in the day simply got used
to backslashes looking like Yen signs.

The Rationale also makes it clear that trigraphs, digraphs, and
<iso646.h> were all invented (not all at the same time) to solve the
same class of problems.

--
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 */