Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> It sounds so wrong, not matching anything I've experienced in the
> programming languages I heard about and about compiler construction
> that I can only express my astonishment about such a statement. The
> poster's statement itself is not explained, though, and if anything,
> the poster should first explain what makes him "pretty sure" about
> it before we can exchange arguments.

Well, I said I was "pretty sure" simply because there are probably
hundreds if not thousands of programming languages out there.

It seems rather likely to me that not all of them have
C-like properties.

I suppose it is possible that in some languages out-of-order
evaluation could be what happens, e.g. the "logical AND" operands
could be evaluated in parallel by different CPUs.

But admittedly I cannot give a concrete example.

br,
KK

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> I suppose it is possible that in some languages out-of-order
> evaluation could be what happens, e.g. the "logical AND" operands
> could be evaluated in parallel by different CPUs.

I did some searching and finally found a suitable result.
According to:

https://en.wikipedia.org/wiki/Logical_disjunction

"Logical disjunction is usually short-circuited; that is,
if the first (left) operand evaluates to true, then the
second (right) operand is not evaluated. The logical
disjunction operator thus usually constitutes a
sequence point.

In a parallel (concurrent) language, it is possible to
short-circuit both sides: they are evaluated in
parallel, and if one terminates with value true, the
other is interrupted. This operator is thus called
the parallel or."

So that describes "parallel logical OR". If this is
possible in a parallel language, then surely
"parallel logical AND" is also doable because in
that case you can terminate the evaluation when
one of the operands turns out to be false.

The Wikipedia article seems to assume that these
logical operators take just two operands, but as
we know from some languages (LISP?), AND or OR can
be generalized to accept any number of operands.

br,
KK

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 24.01.2024 00:10, Keith Thompson wrote:
>>
>> 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.
>
> I think this is the most likely explanation; the restricted _keyboards_
> (and not the restricted [ASCII] character set). Matches my experiences
> with old keyboards I used decades ago.

Well, keyboards and displays. Your keyboard has something other than a |
key, and when you type that, you get a character similar to the one
on the keyboard. They happen to have the same character code as the
ASCII/ISO 646 base character |. When you read someone's soure code,
you see that character where the code has | and ||.

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

On 24/01/2024 13:54, David Brown wrote:
> On 24/01/2024 13:20, Malcolm McLean wrote:
>>
> Many operators in C are not mathematical operations.  "sizeof" is an
> operator, so are indirection operators, structure member access
> operators, function calls, and the comma operator.
>
I've discussed this ad infinitum with people who don't really understand
what the term "function" means. Anththing that maps one set to another
set such that there is one and only one mapping from each member if the
struture set to the result set is mathematically a "function".
Sizeof clearly counts.
>
> Exponentiation is not particularly common in programming, except for a
> few special cases - easily written as "x * x", "x * x * x", "1.0 / x",
> or "sqrt(x)", which are normally significantly more efficient than a
> generic power function or operator would be.
>
It's pretty common in the sort of programming that I do. But this is
fair point. A lot of programs don't apply complex transformations to
data in the way that mine typically do.
>
> That is not an argument against having an operator in C called "pow". It
> is simply not useful enough for there to be a benefit in adding it to
> the language as an operator, when it could (and was) easily be added as
> a function in the standard library.
>
> (It could not have been added as "**", because - as Keith said in
> another post - "x ** y" already has a meaning in C.  While I believe it
> would be possible to distinguish the uses based on the type of "y",
> other than for the literal 0, having "x ** y" mean two /completely/
> different things depending on the type of "y" would not be a good idea
> for C.)
>
Yes, ** and ^, which are the two common ASCII fallbacks, are already
taken. But as you said earlier, in reality most exponentiation
operations are either square or cube, or square root. And in C, that
means either special functions or inefficiently converting the exponent
into a double. If pow were an operator, that wouldn't be an issue.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 24/01/2024 13:54, David Brown wrote:
>> On 24/01/2024 13:20, Malcolm McLean wrote:
>>>
>> Many operators in C are not mathematical operations.  "sizeof" is an
>> operator, so are indirection operators, structure member access
>> operators, function calls, and the comma operator.
> >
>I've discussed this ad infinitum with people who don't really understand
>what the term "function" means. Anththing that maps one set to another
>set such that there is one and only one mapping from each member if the
>struture set to the result set is mathematically a "function".
>Sizeof clearly counts.

Just how many angels do you think can dance on that pin?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 24/01/2024 13:54, David Brown wrote:
>> On 24/01/2024 13:20, Malcolm McLean wrote:
>>>
>> Many operators in C are not mathematical operations.  "sizeof" is an
>> operator, so are indirection operators, structure member access
>> operators, function calls, and the comma operator.
>>
> I've discussed this ad infinitum with people who don't really understand
> what the term "function" means. Anththing that maps one set to another
> set such that there is one and only one mapping from each member if the
> struture set to the result set is mathematically a "function".
> Sizeof clearly counts.

Yes, indeed you are right *if* one accepts that the
mathematical meaning is the only acceptable one.

However, the meanings in mathematics and in programming
languages can be different.

For example, despite that some people still
complain that "=" should not be used for assignment
because in mathematics it means equality. It is
just that the meanings of "=" are different in different
contexts.

One can easily argue that sizeof() is not a function
in C because you cannot use function pointers to
refer to it. With C's meaning of functions, you
always can.

So it is not just a matter of mapping elements
of two sets.

br,
KK

On 23/01/2024 21:51, Lawrence D'Oliveiro wrote:
> 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”?
>
Valid function names have to begin with an alphabetical symbol or
(annoyingly for me) an underscore, as do variables. They may not contain
non-alphanumerical symbols except for underscore. It's in the C standard
somewhere.
C operators are all non-alphanumerical symbols, with the exception of
"sizeof". Again, the operators are listed in the C standard.

>
>> 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.
>
No. This isn't circular reasoning. It's a claim which hasn't been backed
up. It's expected that the reader won't ask for this because it is so
obvious that we can give sensible reasons for "sizeof" being a
function-like alphabetical word rather than a symbol. But if you do, of
course I'm sure someone will provide such a justification.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 23/01/2024 21:51, Lawrence D'Oliveiro wrote:
>> 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”?
> >
>Valid function names have to begin with an alphabetical symbol or
>(annoyingly for me) an underscore, as do variables. They may not contain
>non-alphanumerical symbols except for underscore

Dollar symbol ($) is an allowed extension.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 24.01.2024 18:24, James Kuyper wrote:
>> On 1/24/24 03:10, Janis Papanagnou wrote:
>>> On 23.01.2024 23:37, Kalevi Kolttonen wrote:
>>>>
>>>> [...] I am
>>>> pretty sure that not all computer languages
>>>> provide guarantees about the order of evaluation.
>>>
>>> What?!
>>
>> Could you explain what surprises you about that statement?
>
> It sounds so wrong, not matching anything I've experienced in the
> programming languages I heard about and about compiler construction
> that I can only express my astonishment about such a statement. The
> poster's statement itself is not explained, though, and if anything,
> the poster should first explain what makes him "pretty sure" about
> it before we can exchange arguments.

A concrete example:

#include <stdio.h>

static int count(void) {
static int result = 0;
return ++result;
}

int main(void) {
printf("%d %d %d\n", count(), count(), count());
return 0;
}

C does not specify the order in which the arguments are evaluated
(likewise for operands of most operators). This program could produce
any of 6 possible outputs, at the whim of the compiler. (On my system,
I see "3 2 1" with gcc and "1 2 3" with clang; both are perfectly
valid.)

I'm surprised that that surprises you. It's a fairly fundamental
property of C (and also of C++).

[...]

--
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 24/01/2024 16:27, Dan Cross wrote:
> In article <uorbbr$1s2e2$1@dont-email.me>, bart <bc@freeuk.com> wrote:

>> I think you're just making excuses.
>
> Rather, I'm simply explaining the history.
>
>> I used ASR33s extensively and had no trouble typing on them. (Other than
>> a small latency between pressing a key and having it printed that you
>> got used to, but it didn't affect your typing speed.)
>
> Anecdotal. I, too, have typed on an ASR-33. I did not find it
> pleasant and my hands hurt after a short time.

If this is the same terminal that you have to type program source code
on (especially C source!), and edit it, then clearly having two-letter
shell file commands instead of 3 or 4 letters is giving to make little
overall difference to how long development might take, or any fatigue
experienced.

(I don't remember that bit, but maybe my programs were short, and I
could only book terminals for an hour at a time anyway.)

I think it was suggested somewhere that the characteristics of such a
terminal were a reason for the short commands.

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 24.01.2024 18:24, James Kuyper wrote:
>>> On 1/24/24 03:10, Janis Papanagnou wrote:
>>>> On 23.01.2024 23:37, Kalevi Kolttonen wrote:
>>>>>
>>>>> [...] I am
>>>>> pretty sure that not all computer languages
>>>>> provide guarantees about the order of evaluation.
>>>>
>>>> What?!
>>>
>>> Could you explain what surprises you about that statement?
>>
>> It sounds so wrong, not matching anything I've experienced in the
>> programming languages I heard about and about compiler construction
>> that I can only express my astonishment about such a statement. The
>> poster's statement itself is not explained, though, and if anything,
>> the poster should first explain what makes him "pretty sure" about
>> it before we can exchange arguments.
>
> A concrete example:
>
> #include <stdio.h>
>
> static int count(void) {
> static int result = 0;
> return ++result;
> }
>
> int main(void) {
> printf("%d %d %d\n", count(), count(), count());
> return 0;
> }
>
> C does not specify the order in which the arguments are evaluated
> (likewise for operands of most operators). This program could produce
> any of 6 possible outputs, at the whim of the compiler. (On my system,
> I see "3 2 1" with gcc and "1 2 3" with clang; both are perfectly
> valid.)
>
> I'm surprised that that surprises you. It's a fairly fundamental
> property of C (and also of C++).
>
> [...]

I believe Janis knows what you are saying. The object of
discussion was logical operators, not the fact that C's
function arguments have no guaranteed order of evaluation.

However, I already posted a link to Wikipedia that is
on-topic and shows that parallel logical OR and parallel
logical AND are available in some parallel/concurrent
programming languages.

br,
KK

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 23/01/2024 21:51, Lawrence D'Oliveiro wrote:
>> 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”?
>>
> Valid function names have to begin with an alphabetical symbol or
> (annoyingly for me) an underscore, as do variables. They may not
> contain non-alphanumerical symbols except for underscore. It's in the
> C standard somewhere.

The word you're looking for is "identifier". Function names have to be
identifiers.

> C operators are all non-alphanumerical symbols, with the exception of
> "sizeof". Again, the operators are listed in the C standard.

And _Alignof, introduced in C11.

>>> 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.
>>
> No. This isn't circular reasoning. It's a claim which hasn't been
> backed up. It's expected that the reader won't ask for this because it
> is so obvious that we can give sensible reasons for "sizeof" being a
> function-like alphabetical word rather than a symbol. But if you do,
> of course I'm sure someone will provide such a justification.

Most of the operators in C are represented by *punctuators*, sequences
of punctuation characters. The sizeof and _Alignof are keywords, not
punctuators. The standard also refers to "cast operators", so an
operator can have the form ( type-name ).

The above is a statement of facts about the language, not any kind of
value judgement. I see no need to provide a "justification" for the
fact that the sizeof operator is not represented by a punctuator. (All
too often, my explanations of what the C standard says are mistaken for
advocacy.)

You seem to have a strong reaction to the idea that the decision to make
sizeof a keyword was "justified". Would you care to expand on that
reaction? Do you object to it? If so, why?

I've worked in languages where some operators are puncuators (+, -, *, /)
and some are keywords (and, or, xor, rem, mod). I never found it to
be a problem.

--
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 Wed, 24 Jan 2024 07:58:44 -0800, Keith Thompson wrote:

> Trigraphs, digraphs, and <iso646.h> were all introduced to support
> systems that *don't* support the full ASCII character set.

Where is there a national character set that doesn’t support the symbols
for which iso646.h introduces synonyms?

On Wed, 24 Jan 2024 12:24:32 -0500, James Kuyper wrote:

> As quoted, it's a general statement which includes C: "Except as
> specified later, side effects and value computations of subexpressions
> are unsequenced."

It always seemed to me, explicitly specifying an order removes the
potential for parallelization on hardware which might allow it.

On Wed, 24 Jan 2024 18:40:08 -0000 (UTC), Kalevi Kolttonen wrote:

> "Logical disjunction is usually short-circuited ...

I wonder why that shouldn’t apply to anything else. E.g. in

a × (b + c)

if “a” evaluates to zero, why not avoid the computation of “b + c” and
just return zero as the value of the expression?

On Wed, 24 Jan 2024 15:46:04 +0000, bart wrote:

> It's also laughable that I get shouted down when I complain about all
> the extra junk you have to type here:
>
> cc prog.c -o prog -lm

We normally have Makefiles to do that for us.

On Wed, 24 Jan 2024 14:14:39 +0100, David Brown wrote:

> On 24/01/2024 07:35, Lawrence D'Oliveiro wrote:
>
>> On Tue, 23 Jan 2024 21:43:44 -0800, Keith Thompson wrote:
>>
>>> In the Shift-JIS encoding, character 0x5C, which is the backslash in
>>> ASCII and Unicode, is the Yen sign. That means that if a C source
>>> file contains "Hello, world\n", viewing it as Shift-JIS makes it look
>>> like "Hello, world¥n", but a C compiler that treats its input as ASCII
>>> would see a backslash.
>>
>> So what exactly does iso646.h offer to deal with this?
>>
> In Scandinavian language variants of ASCII ...

Relevance to Shift-JIS being?

On Wed, 24 Jan 2024 14:17:04 -0000 (UTC), Lew Pitcher wrote:

> and, yes, COBOL programmers are still in demand, mostly by financial
> institutions that have hundreds of millions of lines of COBOL code to
> maintain.

I suspect a lot of those institutions have already gone out of business,
or are close to going out of business. And the amounts they have to pay
COBOL programmers to maintain their code are hastening that end.

> Are you certain that you want your taxes to be calculated in
> floatingpoint? ;-)

How else would you handle compound interest?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 24 Jan 2024 07:58:44 -0800, Keith Thompson wrote:
>> Trigraphs, digraphs, and <iso646.h> were all introduced to support
>> systems that *don't* support the full ASCII character set.
>
> Where is there a national character set that doesn’t support the symbols
> for which iso646.h introduces synonyms?

Just one example: <https://en.wikipedia.org/wiki/Code_page_1016> has 'ø'
in the slot that ASCII uses for '|'.

I don't believe it's in common use today, but it may have been in 1995.

--
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 Wed, 24 Jan 2024 20:11:33 +0000, Lawrence D'Oliveiro wrote:

> On Wed, 24 Jan 2024 07:58:44 -0800, Keith Thompson wrote:
>
>> Trigraphs, digraphs, and <iso646.h> were all introduced to support
>> systems that *don't* support the full ASCII character set.
>
> Where is there a national character set that doesn’t support the symbols
> for which iso646.h introduces synonyms?

EBCDIC-US, for one. It lacks the CIRCUMFLEX (^) character.

--
Lew Pitcher
"In Skills We Trust"

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 24 Jan 2024 14:17:04 -0000 (UTC), Lew Pitcher wrote:
>> and, yes, COBOL programmers are still in demand, mostly by financial
>> institutions that have hundreds of millions of lines of COBOL code to
>> maintain.
>
> I suspect a lot of those institutions have already gone out of business,
> or are close to going out of business. And the amounts they have to pay
> COBOL programmers to maintain their code are hastening that end.
>
>> Are you certain that you want your taxes to be calculated in
>> floatingpoint? ;-)
>
> How else would you handle compound interest?

In whatever manner is specified by the relevant regulations.

I don't know what those regulations say, but I would not be at all
surprised if some of them require wide fixed-point calculations of some
sort with carefully specified rounding rules.

--
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 Wed, 24 Jan 2024 20:21:37 +0000, Lawrence D'Oliveiro wrote:

> On Wed, 24 Jan 2024 14:17:04 -0000 (UTC), Lew Pitcher wrote:
>
>> and, yes, COBOL programmers are still in demand, mostly by financial
>> institutions that have hundreds of millions of lines of COBOL code to
>> maintain.
>
> I suspect a lot of those institutions have already gone out of business,
> or are close to going out of business.

And who do /you/ bank with? Certainly, in Canada, our major banks are still
going strong, and they /all/ use COBOL.

> And the amounts they have to pay COBOL programmers

COBOL programmers are being offered hourly rates at about $90 CAD or more.
(I checked this morning). OTOH, C++ programmers (for instance) are being
offered hourly rates of $45 CAD or thereabouts. (Again, this morning's
offers on Indeed.com).

> to maintain their code are hastening that end.

>> Are you certain that you want your taxes to be calculated in
>> floatingpoint? ;-)
>
> How else would you handle compound interest?

Fixed point arithmetic, of course. BTW, that's /not/ "integer"
arithmetic.

--
Lew Pitcher
"In Skills We Trust"

On 2024-01-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> (It could not have been added as "**", because - as Keith said in
>> another post - "x ** y" already has a meaning in C. While I believe
>> it would be possible to distinguish the uses based on the type of "y",
>> other than for the literal 0, having "x ** y" mean two /completely/
>> different things depending on the type of "y" would not be a good idea
>> for C.)
>
> The problem with a "**" exponentation operator is lexical. It's common
> to have two consecutive unary "*" operators in declarations and
> expression:
> char **argv;
> char c = **argv;

Clearly, then, the way forward with this ** operator is to wait for the
C++ people to do the unthinkable, and reluctantly copy it some years
later.

Ya know, like what they did with stacked template closers, which are
already the >> operator.

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

On 24/01/2024 21:23, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 24 Jan 2024 07:58:44 -0800, Keith Thompson wrote:
>>> Trigraphs, digraphs, and <iso646.h> were all introduced to support
>>> systems that *don't* support the full ASCII character set.
>>
>> Where is there a national character set that doesn’t support the symbols
>> for which iso646.h introduces synonyms?
>
> Just one example: <https://en.wikipedia.org/wiki/Code_page_1016> has 'ø'
> in the slot that ASCII uses for '|'.
>
> I don't believe it's in common use today, but it may have been in 1995.
>

7-bit modified ASCII sets like this were definitely used for a while.
They were replaced by 8-bit extended ASCII sets, then UTF-8 (though the
Latin-1 and Latin-9 sets are still in common use, especially on
Windows). Both these 8-bit sets and UTF-8 have 7-bit ASCII as a subset,
and thus have no problems with C.

In 1995 I was new in Norway, and only spoke a little Norwegian, so I
used UK English when programming. I believe most Norwegian programmers
also used either US or UK English - being a relatively small country (in
population), almost everything technical here is in English. So C
character sets were never a problem for me when writing code. But
dot-matrix printers were often set to particular international sets - it
was not uncommon for code printouts to have Norwegian letters in place
of ASCII symbols.

It might be interesting to hear from any native Germans who were
programming C at that time. Germany is big enough that people
programmed in German (so comments would be in German, for example), and
their 7-bit ASCII variant (Code page 1011) also had accented letters in
place of some symbols used by C - including "|".

In article <uorq0d$1ueal$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 24/01/2024 16:27, Dan Cross wrote:
>> In article <uorbbr$1s2e2$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>
>>> I think you're just making excuses.
>>
>> Rather, I'm simply explaining the history.
>>
>>> I used ASR33s extensively and had no trouble typing on them. (Other than
>>> a small latency between pressing a key and having it printed that you
>>> got used to, but it didn't affect your typing speed.)
>>
>> Anecdotal. I, too, have typed on an ASR-33. I did not find it
>> pleasant and my hands hurt after a short time.
>
>If this is the same terminal that you have to type program source code
>on (especially C source!), and edit it, then clearly having two-letter
>shell file commands instead of 3 or 4 letters is giving to make little
>overall difference to how long development might take, or any fatigue
>experienced.

That seems subjective.

>(I don't remember that bit, but maybe my programs were short, and I
>could only book terminals for an hour at a time anyway.)
>
>I think it was suggested somewhere that the characteristics of such a
>terminal were a reason for the short commands.

Dunno. That's what some folks on the Multics project told me.
Unix just carried forward what they were familiar with, and they
seemed to think it was easier to type, as well.

Perhaps you personally had a different experience on an ASR-33.
I suppose that's nice for you, but hardly relevant to the
mindset of a different group of people more than 50 years ago.

- Dan C.