On 1/24/2024 6:20 PM, Dan Cross wrote:
> In article <cXisN.134975$taff.87042@fx41.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Wed, 24 Jan 2024 22:13:06 GMT, Scott Lurndal wrote:
[...]
>>> And with crummy string handling and I/O.
>>
>> Ah, I detect sarcasm.
>
> I think you detect crankery. Please don't feed the troll.
[...]

Interesting... I kind of picked up on a potential line as well...

On 1/24/2024 5:23 PM, Kaz Kylheku wrote:
> On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Wed, 24 Jan 2024 20:25:00 -0000 (UTC), Lew Pitcher wrote:
>>
>>> On Wed, 24 Jan 2024 20:11:33 +0000, Lawrence D'Oliveiro wrote:
>>>
>>>> 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.
>>
>> Were any of the EBCDICs official standards anywhere in the world, outside
>> of IBM?
>
> Let's make a song!
>
> (To the tune of Mozart, K265).
>
> A, B, C, D, E-F-G-H, I
>
> dead-space plus/minus, J, K, L-M-N-O-Pie
>
> R, dead-space, tilde, S, T-U-V
>
> A-I-X-Sux, Y use System Z?
>
> I almost know by ebsy-dickee-dee.
>
> Sing "To hell with IBM!" with me.
>

lol! Fwiw, a tune using Cantor Pairing...

https://youtu.be/XkwgJt5bxKI

lol... ;^)

On Thu, 25 Jan 2024 01:37:12 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Wed, 24 Jan 2024 22:13:06 GMT, Scott Lurndal wrote:
>>
>>> 01 STAR-TABLE.
>>> 05 ROW OCCURS 42 TIMES.
>>> 10 KOLUMN PIC X OCCURS 42 TIMES.
>>> ...
>>> 01 MINI-TABLE.
>>> 05 MROW OCCURS 14 TIMES.
>>> 10 MCOL PIC X OCCURS 14 TIMES.
>>
>>*Sigh* Imagine a language without named constants.
>
> I'm not sure of your point - you left out:
>
> 01 COMMANDS-X.
> 05 COMMAND PIC X(3).
> 88 NAVIGATE VALUE "NAV".
> 88 PHASERS VALUE "PHA".
> 88 TORPEDO VALUE "TOR".
> 88 SHIELDS VALUE "DEF".
> 88 DOCK VALUE "DOC".
> 88 LIB-COM VALUE "COM".
> 88 NAV-C VALUE "NAV".
> 88 PHA-C VALUE "PHA".
> 88 TOR-C VALUE "TOR".
> 88 DEF-C VALUE "DEF".
> 88 DOC-C VALUE "DOC".
> 88 COM-C VALUE "COM".
>
> If those aren't named constants, what do you call them?

Sure, they look like named constants or enums. But they can’t truly be
used in place of constants, can they?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 25 Jan 2024 01:37:12 GMT, Scott Lurndal wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>On Wed, 24 Jan 2024 22:13:06 GMT, Scott Lurndal wrote:
>>>
>>>> 01 STAR-TABLE.
>>>> 05 ROW OCCURS 42 TIMES.
>>>> 10 KOLUMN PIC X OCCURS 42 TIMES.
>>>> ...
>>>> 01 MINI-TABLE.
>>>> 05 MROW OCCURS 14 TIMES.
>>>> 10 MCOL PIC X OCCURS 14 TIMES.
>>>
>>>*Sigh* Imagine a language without named constants.
>>
>> I'm not sure of your point - you left out:
>>
>> 01 COMMANDS-X.
>> 05 COMMAND PIC X(3).
>> 88 NAVIGATE VALUE "NAV".
>> 88 PHASERS VALUE "PHA".
>> 88 TORPEDO VALUE "TOR".
>> 88 SHIELDS VALUE "DEF".
>> 88 DOCK VALUE "DOC".
>> 88 LIB-COM VALUE "COM".
>> 88 NAV-C VALUE "NAV".
>> 88 PHA-C VALUE "PHA".
>> 88 TOR-C VALUE "TOR".
>> 88 DEF-C VALUE "DEF".
>> 88 DOC-C VALUE "DOC".
>> 88 COM-C VALUE "COM".
>>
>> If those aren't named constants, what do you call them?
>
> Sure, they look like named constants or enums. But they can’t truly be
> used in place of constants, can they?

There's actually a comp.lang.cobol newsgroup.

--
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 20:09, Keith Thompson wrote:
> 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?
>
To be accused of being a religious fantatic who uses circular argumenton
the basis that I said that choosing the alphabetical word "sizeof"
rather than choosing a symbol (punctuator if you must) for that operator
is a "justified" exception, but without backing that up, is a bit much.

L D'O obviously doesn't know what the term circular reasoning means. As
for whether we can give reasons why it might be justified, I'll throw it
back to you. Can you suggest what K and R's thinking might have been?
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 25/01/2024 00:30, Lawrence D'Oliveiro wrote:
> On Wed, 24 Jan 2024 19:33:09 +0000, Malcolm McLean wrote:
>
>> 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.
>
> It does in the mathematical sense. But in the C sense, a “function” is a
> block of code which is called at runtime with zero or more arguments and
> returns a result (which might be void). It can also have side-effects on
> the machine state.
>
> It helps the discussion to be clear what your terms mean. Otherwise the
> people you are arguing with have a right to be indignant at what they
> might perceive to be wilful obtuseness.
>
You haven't been around for long enough. I said that the C standard's
use of the term "function" to mean "subroutine" was a misuse, and that I
was going to use the term "function", in context, to refer to that
subset of C subroutines which calculate mathematical functions of bits
in the computer's memory. The opposition and outrage that this generated
was incredible, and must have gone on for years.
--
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 20:09, Keith Thompson wrote:
[...]
>> 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?
>>
> To be accused of being a religious fantatic who uses circular
> argumenton the basis that I said that choosing the alphabetical word
> "sizeof" rather than choosing a symbol (punctuator if you must) for
> that operator is a "justified" exception, but without backing that up,
> is a bit much.
>
> L D'O obviously doesn't know what the term circular reasoning
> means. As for whether we can give reasons why it might be justified,
> I'll throw it back to you. Can you suggest what K and R's thinking
> might have been?

Malcolm, I apologize.

I carelessly misread the attributions and wrongly thought that you had
made the "This is how religious people argue" remark. In fact it was
Lawrence D'Oliveiro who made that silly accusation against you, after
you said that the decision to make sizeof a keyword was justified. I'll
try to be more careful.

As for K&R's thinking, I have no particular insight on that. I have no
problem with some operators being represented by symbols and others by
keywords (I'm accustomed to it from other languages), and I don't see
that the decision to make "sizeof" a keyword even requires any
justification.

--
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/24/24 16:11, Kaz Kylheku wrote:
> On 2024-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> 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? As quoted,
>> it's a general statement which includes C: "Except as specified later,
>> side effects and value computations of subexpressions are unsequenced."
>
> Pretty much any language has to guarantee *something* about
> order of evaluation, somewhere.

Not the functional languages, I believe - but I've only heard about such
languages, not used them.

> Like for instance that calculating output is not possible before a
> needed input is available.

Oddly enough, for a long time the C standard never said anything about
that issue. I argued that this was logically necessary, and few people
disagreed with that argument, but I couldn't point to wording in the
standard to support that claim.

That changed when they added support for multi-threaded code to C in
C2011. That required the standard to be very explicit about which things
could happen simultaneously in different threads, and which things had
to occur in a specified order. All of the wording about "sequenced" was
first introduced at that time. In particular, the following wording was
added:

"The value computations of the operands of an operator are sequenced
before the value computation of the result of the operator." (6.5p1)

On Thu, 25 Jan 2024 03:56:13 +0000, Malcolm McLean wrote:

> I said that the C standard's
> use of the term "function" to mean "subroutine" was a misuse ...

Common Python terminology does the same.

Back in Pascal days, a “function” returned a value, while a “procedure”
had some effect on the machine state. If you wanted to refer to both, you
tried a semi-common term like “routine” and hoped they understood.

On 2024-01-25, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> As for K&R's thinking, I have no particular insight on that. I have no
> problem with some operators being represented by symbols and others by
> keywords (I'm accustomed to it from other languages), and I don't see
> that the decision to make "sizeof" a keyword even requires any
> justification.

C has hardly any alphabetical operators only if you don't consider the
statement keywords to be operators!

I.e. you don't consider the "if" in "if (expr) S1 else S2"
to be an operator which evaluates expr, and then chooses
whether to execute S1 or S2.

If you think that way, the terminology in the language backs you up;
it doesn't call them operators.

Yet ?: in expr ? E1 : E2 is identified as an operator.

Is it because it yields a value? Casting is an operator, and
doesn't always yield a value:

(void) expr

The function call parentheses are an operator, and likewise don't always
yield a value:

free(ptr)

No, it's because something involved only with expressions is an
operator, wheras something involved with statements is ... some unnamed
something: "statement keyword" or whatever.

C++ has lambda expressions, which are operators, yielding a value. And
they are involved with statements: lambdas have a statement body,
much like a while statement has a body.

If C adopted similar syntax, the idea that operators don't have anything
to do with the control of statements would go out the window.

Basically, the Lisp people nailed all the concepts and terminology. If
we use that, we can talk about various other languages in a sensible
way.

In declarators, const and restrict work like unary operators,
syntactically in the same phrase structure role as the pointer *,
stacking from right to left together with these:

int *const *restrict p

Again, the language doesn't call "operators" those symbols that guide
the semantics of declarations. In my background, the main symbols that
guide meaning are all operators. in int *p, * is a type construction
operator which derives a pointer.

If I'm talking about C from the outside, as an object/product of
computer science, rather than talking about C programming, I will
tend to use those terms: like C has operators for iteration
such as while and for (which are not called operators in the
specification of that language).

--
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:55, David Brown wrote:
> [...]
> It might be interesting to hear from any native Germans who were
> programming C at that time.

This is matching my profile. (Don't get fooled by my name.) :-)

My faint memories might be the limiting factor, though! :-/

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

The following recollections imply (but also exceed) the C context.
(So you've been warned.)

The systems I used had originally, for example, not used Umlauts.
There's an alternative representation for Ä Ae, Ö Oe, Ü Ue, and
similar the lower case pendants, and using ss for ß. Some/most
mainframes used only uppercase letters. One OS (for the TR 440)
had even German commands; e.g. the "compile" (de: "übersetze")
command was written 'UEBERSETZE' etc. But it's not as simple; the
TR 440 had a few character sets (for punch cards, printer, etc.);
you find it at http://volatile.gridbug.de/TR440-Charactersets.pdf
The CDC we had used 6 bit character sets (but I have no docs for
it. All uppercase, no umlauts. WRT programming; for Pascal there
were alternative representations; e.g. for array elements a[i]
something like a.(i.), and I don't recall having used umlauts.
In Algol keywords were written, I think, with a leading dot like
.begin .int i; .for i .from 1 .to ... (all caps of course)
Unfortunately my only surviving source code from that time (punch
card set and corresponding 132 column printer output) is buried
somewhere in the basement. The C programming I did, I think, on a
Siemens 7.860, which actually was an IBM clone (maybe a 360/370 ?).
Not sure about the OS I used for that; it was either on a VM/CMS or
the Unix variant VM/UTS (Amdahl), both running on that VM platform.
Someone who better knows the IBM platform may have some insights
about the code sets; I have no docs. While we did *not* have to
use trigraphs I don't recall whether we had to use alternative
representations for some of these characters as mentioned above.
I don't recall that I ever used ASCII extensions like umlauts at
these days, neither in comments nor elsewhere. Next instance was
Sun workstations (Sun-OS), no code-set issues here. Later IBM
and HP-UX systems where I think we had coding standards to avoid
umlauts (but not sure). Base was ISO Latin 1, later ISO Latin 9
(ISO 8859-15), and much later UTF-8. Part of the development was
for Windows clients (not done by me), so compatibility with the
Unix platforms was an issue WRT the code pages.
For an European trans-national X.500 based telephone directory we
used the ISO/ITU-T standards/recommendations in exchanged data.
A small BASIC programmable pocket calculator (in the 1980's) used
an "ASCII code table", but it contains only NULL, and positions
0x20 to 0x5f (no lower case letters or umlauts), but it was 8 bit
and supported at positions 251 and 252 the 'pi' character and the
'sqrt' symbol respectively.
In the late 1970's an Olivetti P6060 basic desktop computer used
the ASCII character set (unchanged, as we know it), no umlauts.
In the docs it's named "ISO-CODE TABELLE", but the characters in
the control code block 0-31 had some graphical representations,
and the 8-bit "extended range" was existing but unspecified.
I also found some docs from that time for the Commodore PET 2001
(and CBM series) that we used here; ASCII and display character
set, see http://volatile.gridbug.de/Commodore-Characterset.pdf

So far my faint memories and some docs. It's really hard to recall
such details and there's some inherent uncertainty.

Janis

On 24.01.2024 17:27, Keith Thompson wrote:
>
> (C++, in 2011 IIRC, introduced special handling for the >> token, which
> occurs in things like std::vector<std::vector<int>>).

So you need not any more have to write it with a space as in ...?
std::vector<std::vector<int> >
That's fine.

But I suppose they haven't fixed its precedence in cin<< and cout>>
contexts? (I suppose it's still handled with shl/shr precedence?)

Janis

On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 25 Jan 2024 03:56:13 +0000, Malcolm McLean wrote:
>
>> I said that the C standard's
>> use of the term "function" to mean "subroutine" was a misuse ...
>
> Common Python terminology does the same.
>
> Back in Pascal days, a “function” returned a value, while a “procedure”
> had some effect on the machine state. If you wanted to refer to both, you
> tried a semi-common term like “routine” and hoped they understood.

Lisp was there long before Pacal. In Lisp, there are only functions.
Functions can be pure if written that way, or have side effects.
They take arguments by value. All computation and side effecting is
done via expressions, which yield a value, even assignments.

Lisp also introduced the ternary "if" operator (if expr this that),
as well as short circuiting "and" and "or" (and expr1 expr2 ...)
(or expr1 expr2 ...).

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

On 25/01/2024 03:59, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 24/01/2024 20:09, Keith Thompson wrote:
> [...]
>>> 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?
>>>
>> To be accused of being a religious fantatic who uses circular
>> argumenton the basis that I said that choosing the alphabetical word
>> "sizeof" rather than choosing a symbol (punctuator if you must) for
>> that operator is a "justified" exception, but without backing that up,
>> is a bit much.
>>
>> L D'O obviously doesn't know what the term circular reasoning
>> means. As for whether we can give reasons why it might be justified,
>> I'll throw it back to you. Can you suggest what K and R's thinking
>> might have been?
>
> Malcolm, I apologize.
>
> I carelessly misread the attributions and wrongly thought that you had
> made the "This is how religious people argue" remark. In fact it was
> Lawrence D'Oliveiro who made that silly accusation against you, after
> you said that the decision to make sizeof a keyword was justified. I'll
> try to be more careful.
>
> As for K&R's thinking, I have no particular insight on that. I have no
> problem with some operators being represented by symbols and others by
> keywords (I'm accustomed to it from other languages), and I don't see
> that the decision to make "sizeof" a keyword even requires any
> justification.
>
I looked it up on the web, but I can't find anything that goes back to K
and R and explains why they took that decision. But clearly to use a
word rather than punctuators, as was the case with every other operator,
must have had a reason.
I think they wanted it to look function-like, because it is function,
though a function of a type rather than of bits, so of course not a
"function" in the C standard sense of the term. But all operators are
functions in this sense. However sizeof doesn't map to anything used in
non-computer mathematics. But "size" is conventionally denoted by two
vertical lines. These are taken by "OR", and would be misleading as in
mathematics it means "absolute", not "physical area of paper taken up by
the notation".
So I would imagine that that was why they thought a word would be
appropriate, and these reasons were strong enough to justify breaking
the general patrern that operators are punctuators.
I could be completely wrong of course in the absence of actual
statements by K and R. But this would seem to make sense.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 25/01/2024 02:20, Dan Cross wrote:
> In article <cXisN.134975$taff.87042@fx41.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:

>>>> DISPLAY "CAPTAIN OF THE U.S.S. ENTERPRISE. ".
>>>> DISPLAY " ".
>>>> DISPLAY "PLEASE ENTER YOUR NAME, CAPTAIN ".
>>>> ACCEPT NAME-X.
>>>
>>> And with crummy string handling and I/O.
>>
>> Ah, I detect sarcasm.
>
> I think you detect crankery. Please don't feed the troll.

Yeah. Posting big chunks of random COBOL code that isn't relevant to
anything is of course perfectly fine.

On 24/01/2024 20:17, Lawrence D'Oliveiro wrote:
> 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.

You have 17 different source files like 'prog.c' in the same folder,
each a different program, and are using 4 different compilers, which are
invoked in ad hoc permutations.

So your answer is to just put it all in a makefile (I'd like to see what
you'd put in it) and type 'make', which magically knows your intentions?

On 25/01/2024 06:01, James Kuyper wrote:
> On 1/24/24 16:11, Kaz Kylheku wrote:
>> On 2024-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> 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? As quoted,
>>> it's a general statement which includes C: "Except as specified later,
>>> side effects and value computations of subexpressions are unsequenced."
>>
>> Pretty much any language has to guarantee *something* about
>> order of evaluation, somewhere.
>
> Not the functional languages, I believe - but I've only heard about such
> languages, not used them.
>

I remember a programming task at university around infinite lists in a
functional programming language (not Haskell, but very similar -
arguably its predecessor). We wrote a function returning pi as an
infinite list of decimal digits - the printout of that started long
before the calculation itself was finished!

>> Like for instance that calculating output is not possible before a
>> needed input is available.
>
> Oddly enough, for a long time the C standard never said anything about
> that issue. I argued that this was logically necessary, and few people
> disagreed with that argument, but I couldn't point to wording in the
> standard to support that claim.
>
> That changed when they added support for multi-threaded code to C in
> C2011. That required the standard to be very explicit about which things
> could happen simultaneously in different threads, and which things had
> to occur in a specified order. All of the wording about "sequenced" was
> first introduced at that time. In particular, the following wording was
> added:
>
> "The value computations of the operands of an operator are sequenced
> before the value computation of the result of the operator." (6.5p1)
>

For the most part, even with threads, C defines things in terms of
observable behaviour. The actual order in which things are evaluated,
even when the standard gives the order required by the abstract machine
(such as using sequence points, and the complicated multi-threaded
stuff), the actual implementation can do any kind of re-ordering it
likes as long as there is no change to the observable behaviour.

On 24/01/2024 21:50, Kaz Kylheku wrote:
> 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.

I'm hoping the C++ people while do the sane/unthinkable (cross out one,
according to personal preference) thing and allow Unicode symbols for
operators, which will then be added to the standard library rather than
to the language. Then we'll have "x ↑ y", and no possible confusion.

(It's actually almost fully possible already - all they need to do is
allow characters such as ↑ to be used as macros, and we're good to go.)

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

The "maximum munch" parsing rule seemed like such a good idea, long ago!

On 25/01/2024 07:48, Janis Papanagnou wrote:
> On 24.01.2024 17:27, Keith Thompson wrote:
>>
>> (C++, in 2011 IIRC, introduced special handling for the >> token, which
>> occurs in things like std::vector<std::vector<int>>).
>
> So you need not any more have to write it with a space as in ...?
> std::vector<std::vector<int> >
> That's fine.
>
> But I suppose they haven't fixed its precedence in cin<< and cout>>
> contexts? (I suppose it's still handled with shl/shr precedence?)
>

There's little problem with the precedence - that's one of the reasons
these operators were picked in the first place. You sometimes need
parentheses, but not often.

The problem was with the order of evaluation. Prior to C++17 (where it
was fixed), if you wrote "cout << one() << two() << three();", the order
the three functions were evaluated was unspecified.

On 25.01.2024 13:43, David Brown wrote:
>
> [...] We wrote a function returning pi as an
> infinite list of decimal digits - the printout of that started long
> before the calculation itself was finished!

You had an algorithm for an infinite list of decimals that finished?

I think this formulation will go into my cookie jar of noteworthy
achievements. - And, sorry, I could not resist. :-)

Janis

On 24/01/2024 20:33, Malcolm McLean 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.

Yes, you have - usually at least somewhat incorrectly, and usually
without being clear if you are talking about a "C function", a
mathematical "function", or a "Malcolm function" using your own private
definitions.

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

"sizeof" clearly does not count.

You don't get to mix "mathematical" definitions and "C" definitions.
"sizeof" is a C feature - it makes no sense to ask if it is a
mathematical function or not. It /does/ make sense to ask if it is a
/C/ function or not - and it is not a C function.

At a pinch, you could say that "sizeof" is a mathematical function with
the domain being a subset set of possible expressions and possible types
visible in the program at the time, according to the rules in the C
standards. It would not be useful or helpful, but you /could/ say that.

However, what I wrote was that "sizeof" was not a "mathematical
operation" - not that it was not a function in the mathematical sense.

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

Different tasks have different programming needs.

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

It could certainly still be an issue - it depends entirely on how that
operator were specified, and how it were implemented.

Unlike normal C functions, operators in C can be "overloaded" by type.
But if there were a "pow" operator that fitted with the style of
existing C operators, we would have overloads for "T pow T to T", where
"T" is an integer type (of rank at least that of "int"), or a floating
point type. We would not see the kinds of overloads that would actually
be useful beyond what you get with today's "pow" function, such as
raising floating point numbers to an integer type. We would certainly
not see efficient shortcuts for common cases at the standards level
(though implementations could do what they wanted).

On 25.01.2024 14:07, David Brown wrote:
>
> The problem was with the order of evaluation. Prior to C++17 (where it
> was fixed), if you wrote "cout << one() << two() << three();", the order
> the three functions were evaluated was unspecified.

The last decade or two I haven't been in C++ to any depth. But I'm a bit
surprised by that. The op<< is defined by something like [informally]
stream op<<(stream,value), where "two() << three()" is "value << value",
but "cout << one()" would yield a stream, say X, and "X << two()" again
a stream, etc. So actually we have nested functions
op<<( op<<( op<<(cout, one()), two()), three())
At least you'd need to evaluate one() to obtain the argument for the
next outer of the nested calls.

Janis

On 25/01/2024 12:43, David Brown wrote:
> On 25/01/2024 06:01, James Kuyper wrote:
>> On 1/24/24 16:11, Kaz Kylheku wrote:
>>> On 2024-01-24, James Kuyper <jameskuyper@alumni.caltech.edu> 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? As quoted,
>>>> it's a general statement which includes C: "Except as specified later,
>>>> side effects and value computations of subexpressions are unsequenced."
>>>
>>> Pretty much any language has to guarantee *something* about
>>> order of evaluation, somewhere.
>>
>> Not the functional languages, I believe - but I've only heard about such
>> languages, not used them.
>>
>
> I remember a programming task at university around infinite lists in a
> functional programming language (not Haskell, but very similar -
> arguably its predecessor).  We wrote a function returning pi as an
> infinite list of decimal digits - the printout of that started long
> before the calculation itself was finished!

You can write something like that in C. I adapted a program to print the
first N digits so that it doesn't stop. It looks like this:

int main(void) {
while (1) {
printf("%c",nextpidigit());
}
}

(The output starts as "314159..."; it will need a tweak to insert the
decimal point.)

The algorithm obviously wasn't mine; I've no idea how it works. (Tn a
sequence like ...399999999..., how does it know that 3 is a 3 and not a
4, before it's calculated further? It's magic.)

The nextpidigit() function is set up as a generator.

It also relies on using big integers (I used it to test my library), so
will rapidly get much slower at calculating the next digit.

Even with a much faster library, eventually memory will be exhausted, so
this is not suitable for an 'infinite' number, or even an unlimited
number of digits; it will eventually grind to a halt.

Was yours any different?

On 25/01/2024 04:56, Malcolm McLean wrote:
> On 25/01/2024 00:30, Lawrence D'Oliveiro wrote:
>> On Wed, 24 Jan 2024 19:33:09 +0000, Malcolm McLean wrote:
>>
>>> 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.
>>
>> It does in the mathematical sense. But in the C sense, a “function” is a
>> block of code which is called at runtime with zero or more arguments and
>> returns a result (which might be void). It can also have side-effects on
>> the machine state.
>>
>> It helps the discussion to be clear what your terms mean. Otherwise the
>> people you are arguing with have a right to be indignant at what they
>> might perceive to be wilful obtuseness.
> >
> You haven't been around for long enough. I said that the C standard's
> use of the term "function" to mean "subroutine" was a misuse, and that I
> was going to use the term "function", in context, to refer to that
> subset of C subroutines which calculate mathematical functions of bits
> in the computer's memory. The opposition and outrage that this generated
> was incredible, and must have gone on for years.

There is no single consensus of the definitions of the terms "function"
or "subroutine" in computing terminology, rendering your argument moot.

There is, however, a very clear understanding of the term "function" in
the context of C - thus in comp.lang.c., the unqualified term "function"
means no more and no less than what the C standards say the term means.

And there is an established mathematical meaning of the term "function"
- a "mathematical function" is a mapping from one set to another set.

These are very different things. They may not be quite as different as,
say, the meaning of the word "character" in the context of C, and it's
meaning in the context of a Shakespeare play. But they are still very
distinct, and it is counter-productive to mix them.

Remember, no one really cares what you said about them, or whether you
think the C founding fathers used a poor choice of terms. It doesn't
even matter if anyone agrees with that opinion, or thinks Nim got it
right by distinguishing "func" and "proc". This is comp.lang.c, where
the focus is on the C language - and we use its terms, definitions and
rules regardless of how we may feel about them.

I don't think the "opposition and outrage" against your ideas has been
incredible - I think people have simply been frustrated at your
insistence of writing confusing and unhelpful posts. The only
incredible thing is that you continue you this nonsense no matter how
often and how carefully people explain that you are wrong - and that
even if you were right, you'd /still/ be wrong here in c.l.c.

On 25/01/2024 13:01, David Brown wrote:
> On 24/01/2024 21:50, Kaz Kylheku wrote:
>> 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.
>
> I'm hoping the C++ people while do the sane/unthinkable (cross out one,
> according to personal preference) thing and allow Unicode symbols for
> operators, which will then be added to the standard library rather than
> to the language.  Then we'll have "x ↑ y", and no possible confusion.
>
> (It's actually almost fully possible already - all they need to do is
> allow characters such as ↑ to be used as macros, and we're good to go.)
>

Suppose ↑ could be used in as macro now, what would such a definition
look like?

Surely you'd be able to invoke it as ↑(x, y)?