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.

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". I don't have any idea what
"conditional and" is supposed to mean, except that the explanation you
provide matches the term "Logical AND".

bart <bc@freeuk.com> wrote:
> Presumably everyone knows what AND and OR mean. So
> why not just use AND and OR?

Maybe back in the early days of C even a one byte
mattered? strlen("AND") is 3 and strlen("&&") is 2.
So they chose "&&" and then "||" was chosen because
of symmetry? Just speculation, of course.

Dennis Ritchie has said that he regretted the
spelling of creat(2) function. Presumably the
abbreviation was supposed to save one byte of
storage.

Anyway, sorry for the off-topic, but Python aims to
be like what you say. It should be like executable
pseudo-code in the sense that your carefully written
code reads almost like plain English. I once wrote
a 300 line Python script without any comments simply
because all the identifiers were long enough and
carefully chosen so that comments were not needed.

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 ("_").

I find that decision wrong.

br,
KK

On 23/01/2024 19:32, Kalevi Kolttonen wrote:
> bart <bc@freeuk.com> wrote:
>> Presumably everyone knows what AND and OR mean. So
>> why not just use AND and OR?
>
> Maybe back in the early days of C even a one byte
> mattered?

Plenty of languages already existed that used 'and', 'or' and 'not'.

My first language did so as well, and was implemented on a smaller
machine than the first C compiler.

If compact code was advantageous, then you have to wonder about the
considerable amount of punctuation in C.

> strlen("AND") is 3 and strlen("&&") is 2.
> So they chose "&&" and then "||" was chosen because
> of symmetry? Just speculation, of course.

Why two & and two |? Was '|' even commonly available on keyboards at the
time? I'm pretty sure 'o' and 'r' were!

Although whether in lower case, I don't know. If not, then just typing
'if' was going to be a problem.

> Dennis Ritchie has said that he regretted the
> spelling of creat(2) function. Presumably the
> abbreviation was supposed to save one byte of
> storage.

Such identifiers would been exposed to external tools such as assemblers
and linkers, which may have had their own limits. Keywords such as 'and'
are internal to the C compiler.

> Anyway, sorry for the off-topic, but Python aims to
> be like what you say. It should be like executable
> pseudo-code

That's a good idea. I've often wondered why, if pseudo-code is so easy
to understand, why it isn't used more for real languages.

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> bart <bc@freeuk.com> wrote:
>> Presumably everyone knows what AND and OR mean. So
>> why not just use AND and OR?
>
> Maybe back in the early days of C even a one byte
> mattered? strlen("AND") is 3 and strlen("&&") is 2.
> So they chose "&&" and then "||" was chosen because
> of symmetry? Just speculation, of course.
>
> Dennis Ritchie has said that he regretted the
> spelling of creat(2) function. Presumably the
> abbreviation was supposed to save one byte of
> storage.

C's predecessor language B had "&" and "|" operators, bitwise "and" and
"or". It didn't have "&&" or "||". "&" and "|" were used in
expressions like:

if (x > 3 & x < 42)

which was reasonably safe because the "<" and ">" operators always yield
0 or 1.

The logical (not bitwise) and short-circuit "&&" and "||" operators were
added in C and appear in the 1974 C manual. The symbols were a fairly
obvious extension of the existing "& and "|" symbols.

There was probably a fairly strong inclination to use punctation rather
than identifiers for operators. There's no explicit rule to this
effect, but sizeof (and later _Alignof) are the only exceptions to the
pattern.

(Perl did something interesting. It has "&&" and "||" operators like
C's, but it also has "and" and "or" keywords, which have the same
semantics but different precedence.)

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

bart <bc@freeuk.com> writes:
[...]
> But it's OK to justify 'pow' for exponentiation?

"pow" is a library function, not an operator. If C had an exponentation
operator, it would probably have been represented using punctuation
characters, perhaps "**". (Adding a "**" operator now would break some
existing code; `x**y` currently means `x * (*y)`. "^^" might work, but
there doesn't seem to be much demand for an exponentation operator
anyway.)

(Yes, sizeof and _Alignof are operators that use keywords rather than
punctuation symbols. There's no hard rule that operators must be
punctuation, just a general trend.)

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

bart <bc@freeuk.com> wrote:
> On 23/01/2024 19:32, Kalevi Kolttonen wrote:
>> bart <bc@freeuk.com> wrote:
>>> Presumably everyone knows what AND and OR mean. So
>>> why not just use AND and OR?
>>
>> Maybe back in the early days of C even a one byte
>> mattered?
>
> Plenty of languages already existed that used 'and', 'or' and 'not'.

I actually know that but it could have mattered
to Dennis Ritchie to be as succinct as possible.

In the same spirit as UNIX has "ls" not "list", "cp"
not "copy" and "mv" not "move".

> My first language did so as well, and was implemented on a smaller
> machine than the first C compiler.
>
> If compact code was advantageous, then you have to wonder about the
> considerable amount of punctuation in C.

True.

>> strlen("AND") is 3 and strlen("&&") is 2.
>> So they chose "&&" and then "||" was chosen because
>> of symmetry? Just speculation, of course.
>
> Why two & and two |? Was '|' even commonly available on keyboards at the
> time? I'm pretty sure 'o' and 'r' were!

I really do not know. I never thought of that but
it does seem strange especially if one claims
that they wanted to save storage.

I guess some old formal logic books use
a single "&" for logical AND before the operators
became standardized.

> Although whether in lower case, I don't know. If not,
> then just typing
> 'if' was going to be a problem.
>
>
>> Dennis Ritchie has said that he regretted the
>> spelling of creat(2) function. Presumably the
>> abbreviation was supposed to save one byte of
>> storage.
>
> Such identifiers would been exposed to external tools such as assemblers
> and linkers, which may have had their own limits. Keywords such as 'and'
> are internal to the C compiler.

I don't believe strlen("create") == 6 would have
exceeded any limits. Ritchie's regret seems to
confirm that. It implies that he could have chosen
"create" as well, but for some reason he did not
do so.

>> Anyway, sorry for the off-topic, but Python aims to
>> be like what you say. It should be like executable
>> pseudo-code
>
> That's a good idea. I've often wondered why, if pseudo-code
> is so easy to understand, why it isn't used more for real
> languages.

Yes, Python is a nice language but the last time
I checked, an O'Reilly Learning Python book was something
like 2000 pages long...

ChatGPT did not know the answer, but this time Google
did: Learning Python, 5th edition (2013) is 1643 pages.

I have no problem with large texts, but I just have to
live with a proper subset of Python features.

br,
KK

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> Actually, C uses the term "Logical AND". I don't have any idea what
> "conditional and" is supposed to mean, except that the explanation you
> provide matches the term "Logical AND".

The term "conditional and" is probably not so good, but the
meaning of it here refers to the familiar short-circuiting
behaviour of C's "&&". The same behaviour exists in, I
think, all UNIX shells.

If I write this in bash:

rm foo.txt && rm bar.txt

then if the first rm-command fails with a non-zero exit value,
then the second rm-command is not executed at all.

It is similar in C code but the zero evaluation value
there means false, i.e. it is completely opposite of the
UNIX shell.

br,
KK

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 never claimed it was the term used in the standard, regardless
of the use of the word 'specifically'.

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.

On 2024-01-23, David Brown <david.brown@hesbynett.no> wrote:
> 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.

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.

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.

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.

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.

--
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-23, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> 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.

So do true, false, bool, complex, imaginary, errno, assert, fpclassify,
...., and any function supplanted by a macro, such as used to be the case
with getc.

--
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 Tue, 23 Jan 2024 06:47:10 +0100, Janis Papanagnou wrote:

> There's also problems with these names. For example '&&' has not the
> semantics of 'and' but of 'and_then', 'or' is actually 'or_else'.

Funnily enough, that is how the languages that offer those words interpret
them. Not just C and C++.

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

> It breaks the rule that, in C, variables and functions are alphnumeric,
> whilst operators are symbols.

Where is there such a “rule”?

> sizeof is an exception, but a justified one.

This is how religious people argue: they use circular reasoning to say
something is justified because it is justified.

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?

On Tue, 23 Jan 2024 20:32:39 -0000 (UTC), Kalevi Kolttonen wrote:

> If I write this in bash:
>
> rm foo.txt && rm bar.txt

Then the second is only executed if the first one returns zero.

What does C do in this case?

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.

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.

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

There are things wrong with Python you can complain about. But that isn’t
one of them.

On Tue, 23 Jan 2024 12:09:09 -0800, Keith Thompson wrote:

> C's predecessor language B ...

Let me see if I understand the genealogy:

B was an adaptation of Martin Richards’ BCPL. BCPL was a low-level,
typeless language designed for system programming. It originated before
byte-addressable machines became popular. In fact, Richards looked at
adapting BCPL to the PDP-11, and came away unimpressed with the latter’s
architecture.

So B was BCPL adapted by the Bell Labs crew to work on a byte-addressable
machine. But it still didn’t have types. And types turned out to be rather
important to the implementation of a decent OS and accompanying software.
So the Bell Labs came up with the successor language C, which did have
types.

On 2024-01-23, Scott Lurndal <scott@slp53.sl.home> 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.

Also, a bitwise and is logical!

ANSI Common Lisp uses symbols like logand, logior, logxor, ...
for bitwise operations.

When you implement this stuff with electronic gates it is digital logic
circuits. You can read live values in it with a logic probe.

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

On 23/01/2024 21:30, Kaz Kylheku wrote:

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

It shows this is a poor man's way of extending a language's syntax.

It's forgivable in user-code, as there is no other way of doing it. But
those new operator names are supposed to look like they are built-in.

If they were, you'd be able to do this:

a bitand= b;

Actually, I thought the macros could be used like that. But '&=' needs
to be a single token, not two.

Also, why isn't 'a &&= b' valid? It would just mean 'a = a && b'.

On 2024-01-23, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 23 Jan 2024 20:32:39 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> If I write this in bash:
>>
>> rm foo.txt && rm bar.txt
>
> Then the second is only executed if the first one returns zero.
>
> What does C do in this case?

C also doesn't evaluate the right operand if the left one is
true.

However in C, the following:

a && b || c && d

is parsed like this:

(a && b) || (c && d)

whereas in the shell:

(((a && b) || c) && d)

where I'm using "virtual parentheses". If you actually stick in real
ones, they denote subshell execution in a separate process. (Bash
allows curly braces for command grouping that doesn't create
processes.)

--
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 23/01/2024 22:00, Kaz Kylheku wrote:
> On 2024-01-23, Scott Lurndal <scott@slp53.sl.home> 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.
>
> Also, a bitwise and is logical!

Only on individual bits. The result of A & B can be any value in the
range of A and B's type, not just true and false.

(My tools internally use ANDL/ORL/NOTL for logical versions, and
IAND/IOR/IXOR/INOT for bitwise. I don't use bare AND/OR/NOT. There is
some confusion however with x64 opcodes which use those for bitwise
instructions.)

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

> When you implement this stuff with electronic gates it is digital logic
> circuits. You can read live values in it with a logic probe.

Yes. You put the probe on one signal line to read true or false on that
line.

Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> On 2024-01-23, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 23 Jan 2024 20:32:39 -0000 (UTC), Kalevi Kolttonen wrote:
>>
>>> If I write this in bash:
>>>
>>> rm foo.txt && rm bar.txt
>>
>> Then the second is only executed if the first one returns zero.
>>
>> What does C do in this case?
>
> C also doesn't evaluate the right operand if the left one is
> true.

We are speaking about logical AND evaluation here.

If the left one is *false*, then the evaluation stops
because the whole conjunction is known to false.

If we are talking about logical OR, then if the left
operand is true, then the evaluation stops because
the disjunction is known to be true.

So this distinction between "conditional and" and
"logical and" boils down to the short-circuiting
left-to-right evaluation order that is guaranteed
by C language standard.

We could conceivably have "logical and" with
out-of-order or right-to-left evaluation. I am
pretty sure that not all computer languages
provide guarantees about the order of evaluation.

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

I don't see you you can draw that conclusion. The header
file has been around for over three decades, yet it's not
in common (or even uncommon) use.

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.

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

br,
KK