On 24/01/2024 20:48, Malcolm McLean wrote:
> 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”?

There is no such 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.

6.4.2.1, in the definition of identifiers. (A wide range of other
Unicode letters are allowed as well.)

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

_Alignof has been an operator since C11, and the "typeof" operator is
coming with C23.

C does not have user-defined operators - all operators are defined by
the C standards committee, and documented in the C standards. If they
choose to make an operator called "pow", or "÷", or "multiply_by_7",
that is their prerogative. They are not bound by any rules someone on
Usenet thinks up because of a pattern that they see. Patterns are not
rules.

If the C standards committee ever decide to add more new operators, they
will choose the name based on what is expected to work best for users,
what has the least risk of compatibility issues, what fits best with any
relevant existing extensions, and what is practical to implement. For
the most recent operators, words have made more sense. But if they were
to introduce a "power" operator, they would likely consider both "**"
and "_Pow" as possibilities - and probably other ideas too.

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

On 25/01/2024 14:19, Janis Papanagnou wrote:
> 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?
>

That's the beauty of lazy evaluation!

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

On 25/01/2024 10:55, Malcolm McLean wrote:
> On 25/01/2024 03:59, Keith Thompson wrote:

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

It is not a function in the C sense - "sizeof x" is not like a function
call (where "x" is a variable or expression, rather than a type).
However, many people (myself included) feel it is clearer in code to
write it as "sizeof(x)", making it look more like a function or
function-like macro.

I suspect the prime reason "sizeof" is a word, rather than a symbol or
sequence of symbols, is that the word is very clear while there are no
suitable choices of symbols for the task. The nearest might have been
"#", but that might have made pre-processor implementations more
difficult. Of course any symbol or combination /could/ have been used,
and people would have learned its meaning, but "sizeof" just seems so
much simpler.

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

That's roughly the same reasoning I see. (And I too do not have any
evidence or references for the reasoning.)

bart <bc@freeuk.com> wrote:
> 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?

I think I have said this before: The first mistake in that approach is
lumping all the different C source files in the same directory. You
should use subdirectories for different programs and their corresponding
source files.

Anyway, even in this insane situation, you could use a Makefile. But
typing "make" would not suffice, you would have to use something like:

make <program name>

br,
KK

David Brown <david.brown@hesbynett.no> wrote:
> 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.

Why on earth do you say that?

It makes perfect sense to ask whether C's sizeof() can be
regarded as a mathematical function. And the answer
to that question is just what Malcolm said: Yes, sizeof()
fits perfectly to the definition of a mathematical function.

But in C language it is not a function, but operator.

br,
KK

On 25/01/2024 14:43, bart wrote:
> 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?
>

That's roughly the same sort of thing. Functional programming languages
just make this kind of thing much easier. (Most do - some do not
support lazy evaluation.) So when you write "numbers = [1..]" in
Haskell, you are really setting up a generator function and a data
structure to hold the progress so far.

But it means you can use them just like any other lists, as long as you
don't try to do something that involves going through to the end of the
list (like printing it out in full, or finding its length) - or sooner
or later your machine is going to run out of memory, or the user will
run out of patience.

So a way to do this (which is not intended to be a very efficient
method) is to view numbers as having an integer part (perhaps a "big
integer", or an expandable list of decimal digits) and an infinite list
of decimals. You can then build up functions for adding them,
multiplying them by an integer, multiplying them by other infinite
precision numbers, etc.

Each of these functions returns another infinite list. The generator
function it produces takes its inputs by running the generators of the
sub-expressions, as needed. (In general, you sometimes have to look a
little ahead to check for carries - as long as you don't meet an
infinite list of 9's, this always stops in a finite time.)

Now you make an arctan function, using the formula :

arctan z = z - (z^3)/3 + (z^5)/5 - (z^7)/7 + ...

It's just an infinite list of scaled powers of z, and you apply "sum" to it.

And your final pi is just "pi = 4 * arctan 1". Printing out the first
20 numbers would then be "take 20 pi".

(Or something similar - I don't remember the exact syntax of the
language we used.)

Of course, there's some details to get right in terms of how far you
need to go down the lists to ensure your output so far is correct. This
is particularly true for the arctan, as you have to determine how many
terms of the infinite sum you are adding as well as how far to go down
each term. (It really helps that for |z| < 1, the terms always get
smaller.) And there's scope for optimisation, such as "pre-calculating"
the powers of z so each new term only needs to multiply the previous
term by z². In a functional programming language, that's easy:

zs = z : map ( * z2 ) zs
where z2 = z * z

Once all that's in place, you can try more advanced Machine formula like:

π/4 = 4.arctan(1/5) - arctan(1/239)

and get far faster convergence. If all the rest of the bits are in
place correctly, only that last line needs to be changed to use the more
efficient formula.

Of course you can do this sort of thing in C, using generator functions.
But it's a lot easier when the language handles all the implementation
detail for you, and lets you use a much simpler syntax. (Simpler when
you are used to it, of course!)

On 25/01/2024 15:57, Kalevi Kolttonen wrote:
> bart <bc@freeuk.com> wrote:
>> 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?

"Any sufficiently advanced technology is indistinguishable from magic."

>
> I think I have said this before: The first mistake in that approach is
> lumping all the different C source files in the same directory. You
> should use subdirectories for different programs and their corresponding
> source files.
>
> Anyway, even in this insane situation, you could use a Makefile. But
> typing "make" would not suffice, you would have to use something like:
>
> make <program name>
>

Or you start your makefile with:

..PHONY all
all : prog1 prog2 prog3 prog4

and then by default it will build all the programs.

David Brown <david.brown@hesbynett.no> writes:
> On 25/01/2024 10:55, Malcolm McLean wrote:
>> On 25/01/2024 03:59, Keith Thompson wrote:
>
>>> 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.
>
> It is not a function in the C sense - "sizeof x" is not like a
> function call (where "x" is a variable or expression, rather than a
> type). However, many people (myself included) feel it is clearer in
> code to write it as "sizeof(x)", making it look more like a function
> or function-like macro.

And many people (myself included) feel it is clearer to write it as
`sizeof x`, precisely so it *doesn't* look like a function call, because
it isn't one. Similarly, I don't use unnecessary parentheses on return
statements.

I also write `sizeof (int)` rather than `sizeof(int)`. The parentheses
look similar to those in a function call, but the construct is
semantically distinct. I think of keywords as a different kind of
token than identifiers, even though they look similar (and the standard
describes them that way).

> I suspect the prime reason "sizeof" is a word, rather than a symbol or
> sequence of symbols, is that the word is very clear while there are no
> suitable choices of symbols for the task. The nearest might have been
> "#", but that might have made pre-processor implementations more
> difficult. Of course any symbol or combination /could/ have been
> used, and people would have learned its meaning, but "sizeof" just
> seems so much simpler.

It has occurred to me that if there had been a strong desire to use a
symbol, "$" could have worked. It even suggests the 's' in the word
"size".

But there was no such desire. sizeof happens to be the only operator
whose symbol is a keyword, but I see no particular significance to this,
and no reason not to define it that way. I might even have preferred
keywords for some of C's well-populated zoo of operators. See also
Pascal, which has keywords "and", "or", "not", and "mod".

[...]

--
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 25.01.2024 15:20, David Brown wrote:
> On 25/01/2024 14:19, Janis Papanagnou wrote:
>> 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?
>
> That's the beauty of lazy evaluation!

Erm, yes, I'm familiar with lazy evaluation.

It just doesn't clarify the magic of getting infinite lists from a
finished procedure.

But I don't want to disturb the ethereal beauty of such a sentence
by critical questioning its semantics. :-)

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

Janis

On 25/01/2024 14:53, bart wrote:
> 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)?
>

It would be slightly nasty C++. Are you sure you want to know? Stop
reading now if you are having second thoughts...

Since you can't use ↑ as a macro name, I've used Π below in the sample
function. "x Π y" calls "pow(x, y)", with no overhead.

(Real code like this would use templates to support integer types and
other floating point types, and perhaps also short-cuts for squares,
cubes, and square roots. But I don't want to make it too messy, and it
would also be more of a c.l.c++ topic.)

#include <cmath>

class PowerProxyInner {
double _x;
public:
constexpr PowerProxyInner(double x) : _x(x) {}
friend inline constexpr double operator + (const PowerProxyInner x,
double y);
};

inline constexpr double operator + (const PowerProxyInner x, double y) {
return std::pow(x._x, y);
}

class PowerProxy {
public:
constexpr PowerProxy() {}
friend inline constexpr PowerProxyInner operator + (const
PowerProxy x, double y);
};

inline constexpr PowerProxyInner operator + (double x, const PowerProxy y) {
(void) y;
return PowerProxyInner(x);
}

constexpr inline PowerProxy POWER;

#define Π +POWER+

double test(double x, double y) {
return x Π y;
}

On 25/01/2024 14:57, Kalevi Kolttonen wrote:
> bart <bc@freeuk.com> wrote:
>> 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?
>
> I think I have said this before: The first mistake in that approach is
> lumping all the different C source files in the same directory.

Then you will instead be issuing commands to switch between directories
all the time.

Is that what you do with, say, image files, have a dedicated folder per
picture?

What's wrong having of lots of instances of the same type of file in one
folder? (Most cameras do exactly that.) Then if you had a program P to
operate on an image, you just type:

P file

(Without even an extension if P only works with .jpg for example.)

This is how I think it is reasonable for a compiler for a specific
language to work.

> You
> should use subdirectories for different programs and their corresponding
> source files.
>
> Anyway, even in this insane situation, you could use a Makefile.

A typical session in a console or terminal (at least for me) is typing
commands to copy, create, delete, rename files and folders, or to
navigate between folders, launch programs which have parameters, etc. etc.

Some of those programs could be compilers, others the programs they
generate.

All lots of ad hoc activities with no particular pattern.

You wouldn't put such an arbitrary sequence, that you don't know in
advance anyway, into a script such as a makefile. Only if you see a
repeating pattern that you will invoke repeatedly.

Fortunately most such commands mentioned are sensible: there is rarely
extraneous detail you have to enter over and over again, when it is
something that it should know or assume anyway.

My comment was anyway just highlighting the difference between people
getting uptight about having to type 'list' instead 'ls', and those who
just shrug at having to do 'gcc prog.c -o prog.c -lm ...'. Apparently
that is acceptable.

On 25/01/2024 14:35, Janis Papanagnou wrote:
> 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.
>

Not quite. To simplify :

cout << one() << two()

is parsed as :

(cout << one()) << two()

So "cout << one()" is like a call to "op<<(cout, one())", and the full
expression is like :

op<<(op<<(cout, one()), two())

Without the new C++17 order of evaluation rules, the compiler can
happily execute "two()" before "op<<(cout, one())". The operands to the
outer call need to be executed before the outer call itself, but the
order in which these two operands are evaluated is unspecified (until
C++17).

Note that C++17 only specifies the order in certain cases, such as the
bitwise shift operators.

On 25.01.2024 16:53, David Brown wrote:
> On 25/01/2024 14:35, Janis Papanagnou wrote:
>> 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.
>>
>
> Not quite. To simplify :
>
> cout << one() << two()
>
> is parsed as :
>
> (cout << one()) << two()
>
> So "cout << one()" is like a call to "op<<(cout, one())", and the full
> expression is like :
>
> op<<(op<<(cout, one()), two())

Yes, up to here that's exactly what I said above (with three nestings).

op<<( op<<( op<<(cout, one()), two()), three())

Remove one

op<<( op<<(cout, one()), two())

>
> Without the new C++17 order of evaluation rules, the compiler can
> happily execute "two()" before "op<<(cout, one())". The operands to the
> outer call need to be executed before the outer call itself, but the
> order in which these two operands are evaluated is unspecified (until
> C++17).

If that was formerly the case then the update was obviously necessary.

Functionally there would probably have been commotion if

tmp = op<<(cout, one())
op<<( tmp, two())

and

op<<( op<<(cout, one()), two())

would have had different results.

Is or was there any compiler that implemented that in the "unexpected"
order?

> [...]

Janis

bart <bc@freeuk.com> wrote:
> On 25/01/2024 14:57, Kalevi Kolttonen wrote:
>> bart <bc@freeuk.com> wrote:
>>> 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?
>>
>> I think I have said this before: The first mistake in that approach is
>> lumping all the different C source files in the same directory.
>
> Then you will instead be issuing commands to switch between directories
> all the time.

You can stay in the top level directory where you can do:

make -C <subdirectory> <makefile target>

Make will then descend into the subdirectory but your shell's working
directory will not change.

> Is that what you do with, say, image files, have a dedicated folder per
> picture?

Image files are different in that normally you do not need to
use external programs to generate them like building binary programs
from source code.

But it makes sense to use subdirectories even with pictures. For
example to have a dedicated directory for:

1) Your recent New York holiday
2) Christmas 2023
3) Your rabbits

But having single photos in their dedicated directories does
not sound too great.

> What's wrong having of lots of instances of the same type of file in one
> folder? (Most cameras do exactly that.) Then if you had a program P to
> operate on an image, you just type:
>
> P file
>
> (Without even an extension if P only works with .jpg for example.)

Yes, your C files are the same "type" as they are all C code. But
their content is not related to each other, they are are all for
different programs and should be separated to subdirectories.

But I see that you are not open to this idea that I find obvious
so it is pretty useless to discuss it any longer.

By the way, I have leeched some obscure movies using BitTorrent.

I always put them into their own subdirectories under ~/movies
even though they might contain only one, two or three files
(i.e. the movie itself, maybe a subtitles file and some kind of warez NFO
file).

> This is how I think it is reasonable for a compiler for a specific
> language to work.
>
>> You
>> should use subdirectories for different programs and their corresponding
>> source files.
>>
>> Anyway, even in this insane situation, you could use a Makefile.
>
> A typical session in a console or terminal (at least for me) is typing
> commands to copy, create, delete, rename files and folders, or to
> navigate between folders, launch programs which have parameters, etc. etc.
>
> Some of those programs could be compilers, others the programs they
> generate.
>
> All lots of ad hoc activities with no particular pattern.
>
> You wouldn't put such an arbitrary sequence, that you don't know in
> advance anyway, into a script such as a makefile. Only if you see a
> repeating pattern that you will invoke repeatedly.
>
> Fortunately most such commands mentioned are sensible: there is rarely
> extraneous detail you have to enter over and over again, when it is
> something that it should know or assume anyway.
>
> My comment was anyway just highlighting the difference between people
> getting uptight about having to type 'list' instead 'ls', and those who
> just shrug at having to do 'gcc prog.c -o prog.c -lm ...'. Apparently
> that is acceptable.

Like somebody said: At least on UNIX/Linux/*BSD/Mac you rarely invoke
the compiler directly. Yeah I know you hate them but the commands are
buried inside Makefiles so that you can type easy make commands.

br,
KK

On 25/01/2024 13:29, David Brown wrote:
> 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.
>
No, that's very useful. If you are thinking in a formal, mathematical way.
A "Malcolm" function is a function of bits. So sizeof is also not a
Malcolm function. Whilst the output set is bits (in the Malcolm function
definition, before optimisation, this is normally a minor caveat but not
for sizeof), the input set is the domain of tyes and expressions and not
bits.
But it is definitely a function, in the proper sense of the term. That C
misuses the word is unfortunate, and whilst we have to accept that the
word will be misused in this way in a C context, I don't think that
means we must always misuse it, even when talking about C.

>
> It could certainly still be an issue - it depends entirely on how that
> operator were specified, and how it were implemented.
>
Well the precedent is that + , -, * and / have their normal meanings for
both integers and floating point types. So if we used "^^" for
exponentiation, I would expect it to compile to "x*x" for X^^2, and
"pow(x, 2.0)" for x ^^ 2.0. By passing the double you obviously want to
force the more expensive operation for some reason.
>
> 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).
>
As I said, I would expect a bit more control. But I agree, it's a minor
point, and in reality pow() is likely to be highly optimised by the
compiler.
However one of the reasons for using C is that you know it will be
highly efficent, even if the compiler is very simple.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 25/01/2024 03:59, Keith Thompson wrote:
> However sizeof doesn't map to anything used in
>non-computer mathematics. But "size" is conventionally denoted by two
>vertical lines.

So is absolute value, if I remember the notation correctly.

|value|

Arguing about what Ken and Dennis were thinking seems
particularly fruitless.

Almost as bad as arguing whether sizeof is an operator,
a function or a keyword.

Personally, I always parenthesize the sizeof
non-terminal.

David Brown <david.brown@hesbynett.no> writes:
> On 24/01/2024 21:50, Kaz Kylheku wrote:
>> On 2024-01-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>>> 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.

That's difficult to type -- but they could add a new trigraph! 8-)}

If the committee decides C needs an exponentation operator (which, as
far as I know, nobody has submitted a proposal for), "^^" is available.

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

You'd also need something for ↑ to expand to.

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

It still does. It's simple to describe, and ambiguous cases like
x+++++y should be resolved with whitespace. (">>" was a real problem in
C++, resolved with a special-case rule in C11; C has no such problems of
similar severity.)

--
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-25, bart <bc@freeuk.com> wrote:
> 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?

Putting that into any file at all would be a good start.

The situation can be organized very nicely with GNU make.

compile_xcc = touch $(2) # fictitious
compile_gcc = gcc $(1) -o $(2)

srcs := $(wildcard *.c)

progs.gcc := $(patsubst %.c,%.gcc,$(srcs))
progs.xcc := $(patsubst %.c,%.xcc,$(srcs))
progs := $(progs.gcc) $(progs.xcc)

%.gcc : %.c; $(call compile_gcc,$<,$@)

%.xcc : %.c; $(call compile_xcc,$<,$@)

..PHONY: all clean
all : $(progs)

clean : ; rm -f $(progs)

Now if we type "make", every .c file is built into a .gcc
and .xcc file.

We can use "make whatever.gcc" just to update that, if necessary.

"make clean" removes all the executables.

"make -n" will show commands without running them.

Suppose we want the gcc executables in a gcc/ directory,
and the xcc ones in xcc/. We can make it a bit more complicated,
and actually make the creation of the directory a dependency.
Because the timestamps of directories is irrelevant (only their
existence or absence) we use the "order only prerequisite" feature
of GNU Make, indicated by the | character.

compile_xcc = touch $(2) # fictitious
compile_gcc = gcc $(1) -o $(2)

srcs := $(wildcard *.c)

progs.gcc := $(patsubst %.c,gcc/%,$(srcs))
progs.xcc := $(patsubst %.c,xcc/%,$(srcs))
progs := $(progs.gcc) $(progs.xcc)

gcc/% : %.c; $(call compile_gcc,$<,$@)

xcc/% : %.c; $(call compile_xcc,$<,$@)

% : ; mkdir $@

..PHONY: all clean
all : $(progs)

$(progs.gcc) : | gcc
$(progs.xcc) : | xcc

clean : ; rm -f $(progs); rmdir xcc gcc

Example session:

$ ls
Makefile prog.c
$ make
mkdir gcc
gcc prog.c -o gcc/prog
mkdir xcc
touch xcc/prog
$ ls gcc
prog
$ ls xcc
prog
$ rm -rf gcc
$ make
mkdir gcc
gcc prog.c -o gcc/prog
$ rm -rf xcc
$ make
mkdir xcc
touch xcc/prog
$ make clean
rm -f gcc/prog xcc/prog; rmdir xcc gcc

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

David Brown <david.brown@hesbynett.no> writes:
> On 24/01/2024 20:33, Malcolm McLean wrote:
>> On 24/01/2024 13:54, David Brown wrote:
[...]
>>> 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).

If C added an exponentation operator (let's say "^^"), there's no reason
it couldn't distinguish between integer and floating-point exponents.

For the "*" operator, the "usual arithmetic conversions" are performed
on the operands; this converts them to the same type. There is no
integer*floating multiplication operation.

For the "<<" and ">>" operators, there's no need for the operands to be
of the same type. Only the "integer promotions" are performed on each
operand separately, converting narrow integer types to int or unsigned
int. Similarly, there's no need for the operands of an exponentiation
operator to have the same type.

For a hypothetical "^^" exponentation operator, I suggest that:

- Each operand can be of either integer or floating type.
- An operand that is of integer type has the integer promotions applied
to it (promoting narrow integers to int or unsigned int).
- If the right operand is of integer type, the semantics are defined in
terms of repeated multiplication, followed by taking the reciprocal if
the right operand is negative.
- 2 ** 3 == 8
- 2.0 ** 3 == 8.0
- 2.0 ** (-3) == 0.125
- 2 ** (-3) == 0 (since 1/8 == 0 in integer arithmetic).
- If the left operand is of integer type and the right operand is of
floating type, the left operand is promoted to a floating type
(perhaps the type of the right operand).
- If the right operand is of floating type, the semantics are defined as
something like exp(log(x) * y), or perhaps something with better
mathematical behavior.

Thus x^^2 would be a reasonably subsitute for x*x, and could be expected
to perform just as well if the right operand is a constant.

Complex and imaginary types add another layer of *ahem* complexity that
I've ignored here.

As for the operator symbol, a new "pow" keyword (`x pow y`) would have
been fine if it had been added in the 1980s, but it would conflict with
the existing pow() function from <math.h> and break existing code. I
suppose the keyword would have to be _Pow, but that's ugly enough that I
prefer "^^".

Again, there's probably not enough demand to make it likely to appear in
a future C standard, but that doesn't stop me from having ideas of what
it should look like if it is added.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> No, that's very useful. If you are thinking in a formal, mathematical way.
> A "Malcolm" function is a function of bits. So sizeof is also not a
> Malcolm function. Whilst the output set is bits (in the Malcolm
> function definition, before optimisation, this is normally a minor
> caveat but not for sizeof), the input set is the domain of tyes and
> expressions and not bits.
> But it is definitely a function, in the proper sense of the term. That
> C misuses the word is unfortunate, and whilst we have to accept that
> the word will be misused in this way in a C context, I don't think
> that means we must always misuse it, even when talking about C.
[...]

You insist that the proper meaning of "function" can only be what
you say it is. That's what a lot of us find tedious and misleading.

According to dictionary.com, the English word "function" goes back to
the 1500s with the meaning "a performance, execution". The mathematical
meaning presumably came later (and mathematical terminology can be quite
flexible, often defined in an ad hoc manner within a paper).

Different fields define different meanings for domain-specific terms,
often using English words that have existing meanings. Mathematicians
introduced their own meaning(s) for the existing word "function".
Computer scientists did the same, with a meaning based on the
mathematical meaning but evolving to refer to how a function is
implemented in a particular language. In everyday English, "function"
often means something like "purpose". C has a very precise meaning for
the word "function" that differs from the mathematical meaning -- **and
there is nothing wrong with that**.

You don't like it? That's fine, but consider trying to communicate
clearly anyway. Feel free to use terms like "mathematical function",
"pure function", or even "Malcolm function" if you insist. But if you
use the unqualified word "function" with a different meaning while
talking about C, you'll get the negative feedback that I can only assume
you're looking for.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

bart <bc@freeuk.com> writes:
[...]
> My comment was anyway just highlighting the difference between people
> getting uptight about having to type 'list' instead 'ls', and those
> who just shrug at having to do 'gcc prog.c -o prog.c -lm
> ...'. Apparently that is acceptable.

We type "ls" instead of "list" because "ls" is the name of the command.
Nobody here was involved in the decision to use that name. According to
some sources, the reason was the difficulty of typing on an ASR-33. It
was likely also influenced by the existence of command aliases on
Multics.

Nobody would complain about having to type "list" if that were the name
of the command. (I do have short aliases for some common commands, but
they're for my personal use and I don't expect anyone else to use them.)

Yes I find having to type "gcc prog.c -o prog -lm" acceptable. I'll do
exactly that for a quick and dirty single-file C program. For a larger
project, I'll use whatever build system the project uses -- sometimes a
Makefile, sometimes something else. If "gcc prog" did the same thing,
I'd use that.

--
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 25/01/2024 18:06, Kaz Kylheku wrote:
> On 2024-01-25, bart <bc@freeuk.com> wrote:
>> 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?
>
> Putting that into any file at all would be a good start.

You're sort of missing the point. There is no actual project here. This
is a set of small test programs. The set may grow or shrink.

I may try different compilers, or perhaps the same one with different
options. Or I might try versions in a different language. Or work with
intermediate obj or asm files.

I just want to have those invocations as minimal as possible and as
flexible as possible without adding an extra layer of indirection via
scripting (and in a syntax that I find impossible) when it's not needed.

When I need scripting, it'll likely be to chain together two more ops in
order to compile and test.

Actually one use-case, which is to compile A.c to A.exe with one
compiler, run it, and then compile A.c to A.exe with another compiler,
would run foul of how make works, which is to not recompile A.c because
it thinks A.exe is up-to-date.

Now you have to start fighting it, and even then you're never quite sure
if you have the latest EXE.

(Actually, gcc's habit of naming everything a.exe instead of prog.exe
helps here, provided you remember it is a.exe. But it also hinders it,
since a.exe clashes with my A.exe above (Windows being case
insensitive.) 'A.c' was not specially chosen for my example, it was a
coincidedence.)

In short I just want to manually type these ad hoc commands from the
command like I do anything else. I don't appreciate long-winded versions
or ones which work differently from everything else.

> The situation can be organized very nicely with GNU make.
>
>
> compile_xcc = touch $(2) # fictitious
> compile_gcc = gcc $(1) -o $(2)
>
> srcs := $(wildcard *.c)
>
> progs.gcc := $(patsubst %.c,%.gcc,$(srcs))
> progs.xcc := $(patsubst %.c,%.xcc,$(srcs))
> progs := $(progs.gcc) $(progs.xcc)
>
> %.gcc : %.c; $(call compile_gcc,$<,$@)
>
> %.xcc : %.c; $(call compile_xcc,$<,$@)
>
> .PHONY: all clean
> all : $(progs)
>
> clean : ; rm -f $(progs)
>
>
>
> Now if we type "make", every .c file is built into a .gcc
> and .xcc file.
>
> We can use "make whatever.gcc" just to update that, if necessary.
>
> "make clean" removes all the executables.
>
> "make -n" will show commands without running them.
>
> Suppose we want the gcc executables in a gcc/ directory,
> and the xcc ones in xcc/. We can make it a bit more complicated,
> and actually make the creation of the directory a dependency.
> Because the timestamps of directories is irrelevant (only their
> existence or absence) we use the "order only prerequisite" feature
> of GNU Make, indicated by the | character.
>
>
>
> compile_xcc = touch $(2) # fictitious
> compile_gcc = gcc $(1) -o $(2)
>
> srcs := $(wildcard *.c)
>
> progs.gcc := $(patsubst %.c,gcc/%,$(srcs))
> progs.xcc := $(patsubst %.c,xcc/%,$(srcs))
> progs := $(progs.gcc) $(progs.xcc)
>
> gcc/% : %.c; $(call compile_gcc,$<,$@)
>
> xcc/% : %.c; $(call compile_xcc,$<,$@)
>
> % : ; mkdir $@
>
> .PHONY: all clean
> all : $(progs)
>
> $(progs.gcc) : | gcc
> $(progs.xcc) : | xcc
>
> clean : ; rm -f $(progs); rmdir xcc gcc
>
>
>
> Example session:
>
> $ ls
> Makefile prog.c
> $ make
> mkdir gcc
> gcc prog.c -o gcc/prog
> mkdir xcc
> touch xcc/prog
> $ ls gcc
> prog
> $ ls xcc
> prog
> $ rm -rf gcc
> $ make
> mkdir gcc
> gcc prog.c -o gcc/prog
> $ rm -rf xcc
> $ make
> mkdir xcc
> touch xcc/prog
> $ make clean
> rm -f gcc/prog xcc/prog; rmdir xcc gcc
>

I'm lost.

On Thu, 25 Jan 2024 14:01:36 +0100, David Brown wrote:

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

Why not do what Algol-68 did, and specify a set of characters that could
be used to define new custom operators?

On Thu, 25 Jan 2024 09:57:43 -0800, Keith Thompson wrote:

> Then we'll have "x ↑ y", and no possible confusion.
>
> That's difficult to type

Compose-circumflex-bar, or compose-bar-circumflex.

↑↑ (typed by me)

On 25/01/2024 18:57, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 24/01/2024 21:50, Kaz Kylheku wrote:
>>> On 2024-01-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> [...]
>>>> 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.
>
> That's difficult to type -- but they could add a new trigraph! 8-)}

Shift-AltGr-U for me. x ￪ y might have been a slightly nicer symbol,
but it's harder to type (for me).

This illustrates the two big difficulties with Unicode symbols for this
kind of thing. Lots of them are difficult to type for many people (at
least, not without a good deal of messing around or extra programs).
And it's easy to have different symbols that appear quite similar as
glyphs, but are very different characters as far as the compiler is
concerned.

>
> If the committee decides C needs an exponentation operator (which, as
> far as I know, nobody has submitted a proposal for), "^^" is available.
>

Well, a logical exclusive or operator would not be much use, so why not?

>> (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.)
>
> You'd also need something for ↑ to expand to.

Yes, but you can write that bit in C++ already. (See my reply to Bart.)

>
>>> 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!
>
> It still does. It's simple to describe, and ambiguous cases like
> x+++++y should be resolved with whitespace. (">>" was a real problem in
> C++, resolved with a special-case rule in C11; C has no such problems of
> similar severity.)
>

Not until we get a ** exponential operator...