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, the | symbol was replaced by
the letter ø or ö. The name "or" is a significant improvement over the
"??!??!" trigraph for ||.

This post appears to me as really odd in many respects (details below),
presuming you mean it as it is formulated [as a general comment] (as
opposed to, maybe, some "very specific" C view). - Where did you get
that view from?

On 24.01.2024 13:20, Malcolm McLean wrote:
>
> Mathematically operators are functions, so a mathematican would say that
> "add" is just as much of a function as "gamma". But to a computer
> programmer an operator compiles to a trivial number of machine code
> instructions, whilst a function is a subroutine call.

We generally don't know; neither what an operator compiles into, nor
what a function compiles into, nor what the compilers and optimizers
additionally do. And I'm not even asking who that ominous "computer
programmer" you have in mind actually is.

I do, for example with matrix a, b, c; c = a * b;
(Or even more difficult tasks.) How should these matrix multiplication
be more trivial than a counterpart with functions?

(Someone already mentioned upthread that functions and operators can
be considered as similar (or in practice probably even equal) things.
Of course this is mostly correct, only that you also have to consider
operator precedence in the second case, and functions are typically
allowing more parameters; most operator are dyadic or monadic, else
you need some additional syntactic support.)

> Pow is not usually
> supported in hardware. However it's such a basic mathematical function
> that it has special notation. So some languages say it should be an
> operator. However ASCII won't represent the standard notation.

Generally this operator is defined by one or more ASCII characters.

> SO there
> are good arguments for and against pow as an operators, and different
> language take differnet views.

Yes, other languages support it (often in various ways; ** ^ 'up' ...)

> But I think the C decision is better, as
> C code is for programming computers,

All the languages that I know to support an operator for power() are
there "for programming computers"...

> not for translating formulae into
> machine readable form.

....and all translate formulas (as part of a program) into machine code.

Janis

In article <uop48a$1dmoe$1@dont-email.me>,
Kalevi Kolttonen <kalevi@kolttonen.fi> 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? 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.

Dennis did not say that; Ken Thompson did. It was a bit of a
gag reply to the question, "if you had to do Unix over again,
what would you change?"

`creat` dates from PDP-7 Unix, and the PDP-7 was word oriented.
It's unclear why it's spelled that way, however; there was also
a `rename` system call that uses the full 6 characters for its
name. Perhaps because internally, `creat` calls a subroutine
called `icreat` which has a full six character name, and there
was a desire for symmetry in the identifiers. Note that
identifiers were limited to six characters on that system,
though `creat` is only 5.

- Dan C.

On 24/01/2024 13:20, Malcolm McLean wrote:
> On 23/01/2024 18:34, bart wrote:
>> 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?
>>
> Mathematically operators are functions, so a mathematican would say that
> "add" is just as much of a function as "gamma".

In mathematics, the term "operator" is usually used for functions where
the domain itself involves functions - such as the Laplace
transformation, or the integral operator. Addition is an /operation/,
not an operator, and "+" is a /symbol/. Given an operation and a
domain, you get a function - addition applied to real numbers is a
function, distinct from addition applied to integers or complex numbers.

> But to a computer
> programmer an operator compiles to a trivial number of machine code
> instructions, whilst a function is a subroutine call.

Not at all.

People working in most high level languages do not think in terms of
generated machine code at all, or in terms of subroutine calls. And C
programmers who are looking closely enough at efficiency and generated
code to be interested in the implementation details, should know that
function calls do not equate to machine-code subroutine calls, nor do
operators necessarily compile to small numbers of machine code instructions.

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. These don't
correspond to machine code instructions in any straightforward manner -
nor do they match subroutine calls. They are specific parts of the
syntax and grammar of the language, and can do things that functions
cannot do in C.

> Pow is not usually
> supported in hardware. However it's such a basic mathematical function
> that it has special notation.

There are vast numbers of things in mathematics that have special notation.

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.

> So some languages say it should be an
> operator. However ASCII won't represent the standard notation. SO there
> are good arguments for and against pow as an operators, and different
> language take differnet views. But I think the C decision is better, as
> C code is for programming computers, not for translating formulae into
> machine readable form.
>

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

On Wed, 24 Jan 2024 09:06:22 +0100, Janis Papanagnou wrote:

> On 23.01.2024 21:13, Keith Thompson wrote:
>> [...] There's no hard rule that operators must be
>> punctuation, just a general trend.)
>
> Anyone still writing "MULTIPLY a BY b GIVEN c" ? :-)

ITYM

MULTIPLY A BY B GIVING C.

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

> (Luckily I've never programmed in COBOL, even after
> it allowed "COMPUTE c = a * b" (or some such).)

I have (lucky me :-) ).

While I don't tout COBOL as the "be all and end all" of
programming languages, it still can perform a lot of
useful work, especially in fields where exact calculations
are required and rounding and truncation of mathematical
operations are well defined. Such as financial institutions.

These days, it even supports object oriented code.
FWIW, the last ISO COBOL language standard was issued in 2023.

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

--
Lew Pitcher
"In Skills We Trust"

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

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

Back when I was learning Unix and C (late 1970s), the consensus belief
in my department was that they were simply poor typists. So many
commands that use two letters, one that can be typed with each hand, or
commands that are one letter repeated (I've got a dd copying a disk
image even as we speak).

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> Back when I was learning Unix and C (late 1970s), the consensus belief
> in my department was that they were simply poor typists. So many
> commands that use two letters, one that can be typed with each hand, or
> commands that are one letter repeated (I've got a dd copying a disk
> image even as we speak).

That could well be. Or maybe they wanted terse
commands so that everybody could enter them quicker.

I am actually a big fan of those short commands. It
is not difficult to remember them and they are
so fast to enter.

br,
KK

In article <1bbk9a4wi2.fsf@pfeifferfamily.net>,
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>[snip]
>>> 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.
>
>Back when I was learning Unix and C (late 1970s), the consensus belief
>in my department was that they were simply poor typists. So many
>commands that use two letters, one that can be typed with each hand, or
>commands that are one letter repeated (I've got a dd copying a disk
>image even as we speak).

The two-letter command thing dates from Multics, where most
commands had a "long" form (e.g., `list`) and a short form
(`ls`).

It is true that they were using teletypes like the ASR-33, which
were both slow and difficult to type on (more force required per
keystroke compared to modern keyboards), so brevity was prized.
Also, line rates were very slow, 110 or 300 BAUD; economy of
expression giving brevity lead to greater throughput.

One sees this carry through to B: in Dennis Ritchie's paper on
the history of C, one sees that many of the characteristics of
B were designed to economize on space, as the PDP-7 was a small
machine. https://www.bell-labs.com/usr/dmr/www/chist.html

- Dan C.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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?

Trigraphs, digraphs, and <iso646.h> are all solutions for systems that
don't support all ASCII printable characters.

Are you arguing for the sake of arguing, or is there something here that
you don't understand?

Did you read the section of the C99 Rationale that I cited earlier?
If not, please do.

--
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-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 23 Jan 2024 06:54:56 +0100, Janis Papanagnou wrote:
>
>> ... in my professional contexts there where even [coding] standards
>> defined that you had to follow.
>
> What about the open-source code that your company takes without paying? Do
> you demand that that code follow your rules as well? Do you send it back
> to the developers to demand they rewrite it for you?

In my experience, when you patch third-party code, you closely adhere to
*its* conventions, to keep it consistent.

If you're a person who maintains an diverse open source stack for an
organization, you end up working with numerous coding conventions.

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

On 24/01/2024 15:17, Dan Cross wrote:
> In article <1bbk9a4wi2.fsf@pfeifferfamily.net>,
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>> [snip]
>>>> 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.
>>
>> Back when I was learning Unix and C (late 1970s), the consensus belief
>> in my department was that they were simply poor typists. So many
>> commands that use two letters, one that can be typed with each hand, or
>> commands that are one letter repeated (I've got a dd copying a disk
>> image even as we speak).
>
> The two-letter command thing dates from Multics, where most
> commands had a "long" form (e.g., `list`) and a short form
> (`ls`).
>
> It is true that they were using teletypes like the ASR-33, which
> were both slow and difficult to type on (more force required per
> keystroke compared to modern keyboards), so brevity was prized.
> Also, line rates were very slow, 110 or 300 BAUD; economy of
> expression giving brevity lead to greater throughput.

I think you're just making excuses.

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

A 110 baud speed means max 10 characters per second, about 120 words per
minute. That's twice as fast as an expert typist on a modern keyboard.

So it's hardly as though that was the limiting factor.

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

compared with a minimal:

cc prog

but the use of 2-letter abbbreviations to save having to type out a 3 or
4-letter word (which is easier and quicker to type type than random
punctuation) gets lauded.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>
>> 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.
>
>Back when I was learning Unix and C (late 1970s), the consensus belief
>in my department was that they were simply poor typists.

It's difficult to type quickly on an ASR-33, I suspect that
would have part of the reason for short commands. Two
letter commands were common on the burroughs mainframes
in the 60s and 70s and likely on other systems as well.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 23.01.2024 22:30, Kaz Kylheku wrote:
[...]
>> 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.

Not quite, see below.

> I don't quite understand your thought. The "6-bit characters" OSes
> that I used had no lowercase letters, as opposed to IA5/ASCII/ISO646.
>
> To be sure I had also re-inspected the ASCII character set and it
> seems that all C characters (including these operators) are anyway
> in the ASCII domain. It's beyond me why they've used the name
> "iso646.h".

ISO/IEC 646 is the international standard corresponding to ASCII, a
7-bit character set. C originated on systems that supported the entire
ASCII character set, so the designers felt free to use any printable
ASCII characters (the only ones not used are '$', '`', and '@').

Trigraphs, digraphs, and <iso646.h> were all introduced to support
systems that *don't* support the full ASCII character set. Writing C
code in EBCDIC can be difficult, since for example some versions don't
have '[' and ']'. Some national 7-bit character sets replaced some
ASCII characters with accented letters. The Japanese Shift-JIS has the
Yen sign in the slot that ASCII uses for '\'. Prior to 1995, when
digraphs and <iso646.h> was introduced, some implementers had provided
their own alternate spellings.

Again, see Annex MSE.4 of the C99 Rationale:
http://www.open-std.org/jtc1/sc22/WG14/www/C99RationaleV5.10.pdf

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

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.

Both keyboard and displays, I think. A Japanese keyboard might send
0x5c (the ASCII code for '\`) when you type the Yen character, and the
corresponding display might show that same byte value as the Yen
character. It might not have had the ability to display the '\' glyph,
but the C compiler might still have treated 0x5c as backslash. (I've
never used such a system, so this is speculation.)

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

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;
Adding a "**" operator would have made the above invalid due to the
"maximal munch" rule, before the type of the argument is even
considered.

See also x+++++y, which might be intended as x++ + ++y, but is scanned
as x ++ ++ + y, a syntax error.

C could have added "**" very early, but then we'd have to write
"* *argv" or "*(*argv)".

We have "&&", which could have caused a similar issue for unary "&", but
&(&x) is semantically invalid.

(C++, in 2011 IIRC, introduced special handling for the >> token, which
occurs in things like std::vector<std::vector<int>>).

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

In article <uorbbr$1s2e2$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>On 24/01/2024 15:17, Dan Cross wrote:
>> In article <1bbk9a4wi2.fsf@pfeifferfamily.net>,
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>> [snip]
>>>>> 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.
>>>
>>> Back when I was learning Unix and C (late 1970s), the consensus belief
>>> in my department was that they were simply poor typists. So many
>>> commands that use two letters, one that can be typed with each hand, or
>>> commands that are one letter repeated (I've got a dd copying a disk
>>> image even as we speak).
>>
>> The two-letter command thing dates from Multics, where most
>> commands had a "long" form (e.g., `list`) and a short form
>> (`ls`).
>>
>> It is true that they were using teletypes like the ASR-33, which
>> were both slow and difficult to type on (more force required per
>> keystroke compared to modern keyboards), so brevity was prized.
>> Also, line rates were very slow, 110 or 300 BAUD; economy of
>> expression giving brevity lead to greater throughput.
>
>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.

>A 110 baud speed means max 10 characters per second, about 120 words per
>minute. That's twice as fast as an expert typist on a modern keyboard.
>
>So it's hardly as though that was the limiting factor.
>
>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
>
>compared with a minimal:
>
> cc prog
>
>but the use of 2-letter abbbreviations to save having to type out a 3 or
>4-letter word (which is easier and quicker to type type than random
>punctuation) gets lauded.

That all seems irrelevant to the introduction of two- and three-
letter command names in Unix. Which, as I mentioned, largely
came from Multics.

- Dan C.

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> These days, it even supports object oriented code.
> FWIW, the last ISO COBOL language standard was issued in 2023.

ADD 1 TO COBOL GIVING COBOL

--
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 15:17, Lew Pitcher wrote:
> On Wed, 24 Jan 2024 09:06:22 +0100, Janis Papanagnou wrote:

> ITYM
>
> MULTIPLY A BY B GIVING C.

Memories are faint, and I consider it already pathological that
I still recall (basically) the syntax that I've seen just once,
many decades ago, and never programmen myself! ;-)

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

Yeah, I've heard so.

>
>> (Luckily I've never programmed in COBOL, even after
>> it allowed "COMPUTE c = a * b" (or some such).)
>
> I have (lucky me :-) ).

Hmm, okaaay... :-)

>
> While I don't tout COBOL as the "be all and end all" of

Sounds prophetic like: "the end of all". LOL :-)

> programming languages, it still can perform a lot of
> useful work, especially in fields where exact calculations
> are required and rounding and truncation of mathematical
> operations are well defined. Such as financial institutions.

Yes, sure.

>
> These days, it even supports object oriented code.
> FWIW, the last ISO COBOL language standard was issued in 2023.

Yes, I had noticed (and was astonished) that it's evolution
is still continued.

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

I'm not sure about that. Quite some years ago I have actually
worked (in the country where I am living) on tax software for
the finance authorities. At least the part I was involved was
written in C++. But I cannot tell what the calculation modules
were based on, floating point or else. Though I'm sure they've
chosen a sophisticated calculation base. I doubt it was COBOL.

Janis

On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> To be sure I had also re-inspected the ASCII character set and it
> seems that all C characters (including these operators) are anyway
> in the ASCII domain. It's beyond me why they've used the name
> "iso646.h".

Because the macro names in that header are in the ISO 646
invariant set, expanding to tokens that use characters outside
of the invariant set.

ISO 646 looks liken a effort to standardize the "zoo" of regional ASCII
variants.

It defines a base character set which looks exactly like ASCII (correct
me if I'm wrong) of which there are national variants. It's like a
"mini ISO Latin" in 7 bits.

The Wikipedia page on it is quite good.

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

On 24.01.2024 17:56, Kaz Kylheku wrote:
> On 2024-01-24, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> To be sure I had also re-inspected the ASCII character set and it
>> seems that all C characters (including these operators) are anyway
>> in the ASCII domain. It's beyond me why they've used the name
>> "iso646.h".
>
> Because the macro names in that header are in the ISO 646
> invariant set, expanding to tokens that use characters outside
> of the invariant set.

I forgot about the "national variants" and the, how was it called,
IRV (International Reference Version, or some such)?.

>
> ISO 646 looks liken a effort to standardize the "zoo" of regional ASCII
> variants.
>
> It defines a base character set which looks exactly like ASCII (correct
> me if I'm wrong) of which there are national variants. It's like a
> "mini ISO Latin" in 7 bits.

A common ASCII subset with specific code points around [ ^ ] | etc.

The inherent problem with that is that even many standard symbols
from the C language were a problem; [ ] ^ { } ~ | which are in the
IRV but (prevalently) not in the national variants.

You cannot write legible C code with national non-IRV ASCII variants.

Janis

On 24.01.2024 17:56, Kaz Kylheku wrote:
>
> The Wikipedia page on it is quite good.

The German Wikipedia has a table that is better legible IMO
https://de.wikipedia.org/wiki/ISO_646

Janis

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? As quoted,
it's a general statement which includes C: "Except as specified later,
side effects and value computations of subexpressions are unsequenced."

Now, logical-AND and logical-OR are two cases where the order of
evaluation is, in fact, specified. Are you expressing surprise that
there are other languages where that's not the case? I can't remember
where, but I'm fairly sure I've seen a language where the closest
equivalent of C's (expression1 && expression2) causes both
sub-expressions to be evaluated, in an arbitrary order, before
evaluating the equivalent of && itself. Unfortunately, I don't remember
where.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 24.01.2024 15:17, Lew Pitcher wrote:
>> On Wed, 24 Jan 2024 09:06:22 +0100, Janis Papanagnou wrote:

>> programming languages, it still can perform a lot of
>> useful work, especially in fields where exact calculations
>> are required and rounding and truncation of mathematical
>> operations are well defined. Such as financial institutions.
>
>Yes, sure.

On one of the Burroughs mainframe lines, the disk
defragmentation utility (called SQUASH) was written
in COBOL68.

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.

I may have been lucky that such a fundamental property as operational
semantics defining evaluation order have been part of all languages I
met, especially in the context of expressions connected by operators
we were speaking about here.

> [...]
>
> Now, logical-AND and logical-OR are two cases where the order of
> evaluation is, in fact, specified. Are you expressing surprise that
> there are other languages where that's not the case? I can't remember
> where, but I'm fairly sure I've seen a language where the closest
> equivalent of C's (expression1 && expression2) causes both
> sub-expressions to be evaluated, in an arbitrary order, before
> evaluating the equivalent of && itself. Unfortunately, I don't remember
> where.

In functional languages without side effects it might not be an issue.

The closest I met were theoretical expressions (like e.g. Dijktra's
Guards, or how they were called) in per se non-deterministic contexts.

Janis

On 24.01.2024 18:38, Janis Papanagnou wrote:
> [...]
>
> The closest I met were theoretical expressions (like e.g. Dijktra's
> Guards, or how they were called) in per se non-deterministic contexts.

Ah, I forgot; and I think also in Intercal... - wasn't (at least) the
"politeness check" non-deterministic? - ...in case it matters. :-)

>
> Janis
>