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

There were indeed such real-world cases, complaints were made, and the
rules changed in C++17.

Usually it doesn't matter what order arguments to functions (or operands
to operators) are evaluated. Some compilers have consistent ordering
(and it is often last to first, not first to last), others pick whatever
makes sense at the time. The ordering has been explicitly and clearly
stated as "unspecified" since around the beginning of time (which was,
as we all know, 01.01.1970).

On Thu, 25 Jan 2024 21:07:55 +0100, David Brown wrote:

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

The compose key on *nix systems gives you a fairly mnemonic way of typing
many of them.

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

You can actually take advantage of that. E.g. from some of my Python code:

for cłass in (Window, Pixmap, Cursor, GContext, Region) :
delattr(cłass, "__del__")
#end for

The human reader might not actually notice (or care) that a particular
identifier looks like a reserved word, since the meaning is obvious from
context. The compiler cannot deduce the meaning from that context, but
then, it doesn’t need to.

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

yep, difficult to type.

>
>↑↑ (typed by me)

and to read.

On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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?

That ship sailed. C uses maximal munch lexing which allows operators
to be juxtaposed with no intervening space. E.g. !*++p is tokenized
as {!}{*}{++}{p}. It's difficult to introduce a scheme for defining
new combinations of characters as new kinds of tokens. The only
ASCII glyphs that are not some kind of token already are $ and @;
they are not used in C. So program-defined tokens would have to start
with one of these. If a program-defined token started with something
existing like *, for instance a token *%%*, that already has an existing
meaning; it scans as {*}{%}{%}{*}. Hacky rules, like speculative parses,
and whatnot, could make it work; there is now way something like that
could be standardized into C, though.

We can use *%%* as a symbol in ANSI Lisp, because Lisp has tokenizing
rules which support that. Tokens are made up of token constituent
characters, and are delimited by the first nonconstituent. For instance
( is a non-constituent (for obvious reasons) so *%%*( will be read
properly as the *%%* token (which becomes a symbol object) followed
by an open parenthesis starting a list. Likewise, whitespace is
terminating. The # character has a special meaning in various notations,
and is also a token constituent so that #c(1.0 2.0) is a complex
number, yet ab#c is a single symbol token.

Nothing like this is easy to retrofit into C.

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

On 2024-01-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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)

In Japanese IME: type ue, then space bar several times to find the
completion, which becomes the top one in the LRU list for the
next time you type ue.

Japanese IME is great.

Need an Ohm symbol? o-mu, spacebar: Ω. omega also works.

ha-to: ♥
onpu: ♪
hoshi: ★, ☆

arufa, be-ta, ganma, deruta, ...: α, β, γ, Δ

hidari: ← (and others)
migi: → (and others)
shita: ↓

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

On 25/01/2024 20:06, Lawrence D'Oliveiro wrote:
> 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?

Because that was a terrible scheme. It was too easy to create a language
full of cryptic-looking new operators that no one had any idea what they
did.

It also allowed you to define precedences of any operator, including
overriding the precedence of any operator within a nested scope.

That means that 'a + b * c' could be parsed differently in different
contexts.

Imagine putting that power into the hands of ordinary users.

On Thu, 25 Jan 2024 21:16:14 +0000, bart wrote:

> Imagine putting that power into the hands of ordinary users.

Shock, horror. Of course we elite cannot allow that into the hands of the
plebs. Imagine what they might do!

Kalevi Kolttonen wrote:

> What?! Are you saying that there is no way to label functions as private
> in Python? That sounds absolutely horrible. Why would anyone design a
> language with object-oriented features without support for
> encapsulation?

Frankly, i would like to see that kind of thing adopted everywhere.
Private variables, static subroutines, and opaque types are all things
that serve only to forcibly restrict a programmer. Instead of putting up
a barrier that can be hopped over when it's really necessary, they
establish a thick, unclimbable wall that can never be bypassed even when
you need to.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site

I think that macros should always be shouted, regardless of context,
because as nothing but text replacements they are inherently a little more
spicy to deal with and functionlikemacros are not always interchangeäble
with subroutine calls—for instance, one cannot take the address of a
functionlikemacro like they can with a subroutine.

On the other hand, i've seen instances of people making certain
exceptionally bizzare macros lowercase despite how weird the macros are—
see, for instance, the black magic that is <https://www.libcello.org/>.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
East, west, and C!

On 25.01.2024 21:06, Lawrence D'Oliveiro wrote:
>
> Why not do what Algol-68 did, and specify a set of characters that could
> be used to define new custom operators?

What do you mean by "specify a set of characters that could be used"?

In Algol(68) you can use punctuation characters, letters, or words.
Just declare the operator and its priority.

A few examples from some old test source code on my disk...

OP H = (INT a, b) INT : ( a+b );
PRIO H = 5;
OP ~ = (INT a, b) INT : ( a+b );
PRIO ~ = 5;
IF 2 H 3 = 5 THEN print (62) ELSE print (63) FI;
IF 2 ~ 3 = 5 THEN print (72) ELSE print (73) FI;

PRIO O = 9;
OP O = (INT a, b) INT : a * b;
print ((a O b + 1))

OP MAX = (INT a, INT b) INT : ( a > b | a | b );
PRIO MAX = 4;
print (5 MAX 7);

Janis

On 25.01.2024 23:01, Lawrence D'Oliveiro wrote:
> On Thu, 25 Jan 2024 21:16:14 +0000, bart wrote:
>
>> Imagine putting that power into the hands of ordinary users.
>
> Shock, horror. Of course we elite cannot allow that into the hands of the
> plebs. Imagine what they might do!

Power to the people!

Janis

On 2024-01-26, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 25.01.2024 23:01, Lawrence D'Oliveiro wrote:
>> On Thu, 25 Jan 2024 21:16:14 +0000, bart wrote:
>>
>>> Imagine putting that power into the hands of ordinary users.
>>
>> Shock, horror. Of course we elite cannot allow that into the hands of the
>> plebs. Imagine what they might do!
>
> Power to the people!

And through the chairs of bad people!

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

On 25.01.2024 21:11, David Brown wrote:
> On 25/01/2024 17:11, Janis Papanagnou wrote:
>> 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?
>>
>
> There were indeed such real-world cases, complaints were made,

Complaints that the rule was not clear in its definition?
Or complaints that their compiler did not support cout<<a<<b<<c;
correctly? - I would be astonished about the latter.
This is so fundamental a construct and so frequently used that any
compiler would have been withdrawn in the week after it came out.
That is my expectation. So I would be grateful if you could provide
some evidence that I can look up.

Mind that even if two() is evaluated before one(), it will not be
output before the stream of the first expression op<<(cout, one())
is available, and for this one() must be evaluated. Then one() can
be sent to the stream, and then also two() can be sent to the stream.
(Am I missing something?)

Janis

> and the rules changed in C++17.
>
> Usually it doesn't matter what order arguments to functions (or operands
> to operators) are evaluated. Some compilers have consistent ordering
> (and it is often last to first, not first to last), others pick whatever
> makes sense at the time. The ordering has been explicitly and clearly
> stated as "unspecified" since around the beginning of time (which was,
> as we all know, 01.01.1970).

On 25/01/2024 19:20, Keith Thompson wrote:
> 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.
>
We could say that in comp.lang.c "function" shall mean "a subroutine"
and carry no other meaning. But then either we can't talk about
subroutines which calculate "functions" [prohibited word] of bits at
all, which isn't really an acceptable restriction, or we have to invent
another term. So "Malcolm function" is workable, but has the disadvantge
that whilst regulars know what a "Malcolm function" is, the term is not
going to be familiar to anyone coming to the group for the first time,
and that "Malcolm functions" are just subroutines which are mathematical
functions". Essentially. Another advantage of "Maclolm function" is that
if we have this special term, we can define it in away which is slightly
different from "mathematical function", and that can help clarify ideas.

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Tue, 23 Jan 2024 22:47:30 -0000 (UTC), Kalevi Kolttonen wrote:
>
>> What?! Are you saying that there is no way to label functions as
>> private in Python? That sounds absolutely horrible. Why would
>> anyone design a language with object-oriented features without
>> support for encapsulation?

I have to admit, this question made me laugh.

> [...]
> Python also has metaclasses. Does your favourite OO language have
> metaclasses?

It does.

But this being comp.lang.c, I am confining my remarks to
commentary related to C.

On 25/01/2024 21:18, Lawrence D'Oliveiro wrote:
> On Thu, 25 Jan 2024 21:07:55 +0100, David Brown wrote:
>
>> 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).
>
> The compose key on *nix systems gives you a fairly mnemonic way of typing
> many of them.
>

It lets you type some, but it is still limited in the default setup.
It's very useful for things like diacriticals on letters that you
already have, but if you want to use it for something out of the
ordinary, you need to make your own .XCompose file. And then you have
to remember to update things on your home computer, work computer,
laptop, etc. So it is very useful (I use it myself), but not an
out-of-the-box solution.

>> 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.
>
> You can actually take advantage of that. E.g. from some of my Python code:
>
> for cłass in (Window, Pixmap, Cursor, GContext, Region) :
> delattr(cłass, "__del__")
> #end for
>
> The human reader might not actually notice (or care) that a particular
> identifier looks like a reserved word, since the meaning is obvious from
> context. The compiler cannot deduce the meaning from that context, but
> then, it doesn’t need to.

I am not at all keen on that. I am not against using non-ASCII letters
as though they were special symbols for particular purposes, but I'd
want them to stand out clearly.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 25/01/2024 19:20, Keith Thompson wrote:
>> 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.
>>
> We could say that in comp.lang.c "function" shall mean "a subroutine"
> and carry no other meaning. But then either we can't talk about
> subroutines which calculate "functions" [prohibited word] of bits at
> all, which isn't really an acceptable restriction, or we have to
> invent another term. So "Malcolm function" is workable, but has the
> disadvantge that whilst regulars know what a "Malcolm function" is,
> the term is not going to be familiar to anyone coming to the group for
> the first time, and that "Malcolm functions" are just subroutines
> which are mathematical functions". Essentially. Another advantage of
> "Maclolm function" is that if we have this special term, we can define
> it in away which is slightly different from "mathematical function",
> and that can help clarify ideas.

Is there any difference between what you call a "Malcolm function" and
what most people would call a "pure function" (a function that returns
the same result for the same arguments and has no side effects)?

Nobody is trying to forbid anything. I'm just saying that the word
"function" when used without qualification should refer to what C calls
a "function". If you mean something other than a C function, just
qualify the word somehow so we know what you're talking about.

We know you don't like the way C uses the word "function". You don't
need to tell us again and again.

--
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 26/01/2024 02:21, Janis Papanagnou wrote:
> On 25.01.2024 21:11, David Brown wrote:
>> On 25/01/2024 17:11, Janis Papanagnou wrote:

>>> Is or was there any compiler that implemented that in the "unexpected"
>>> order?
>>>
>>
>> There were indeed such real-world cases, complaints were made,
>
> Complaints that the rule was not clear in its definition?
> Or complaints that their compiler did not support cout<<a<<b<<c;
> correctly? - I would be astonished about the latter.

The pre-C++17 rule was perfectly clear - there was no specified order of
execution for the operands. (And I thought I'd made /that/ perfectly
clear already.) Compilers all worked correctly - they can hardly have
fallen foul of a rule that did not exist.

The complaints (at least, the ones based on facts rather than
misunderstandings) were about the lack of a rule that enforced
evaluation order in certain cases.

So C++17 added rules for evaluation orders in some circumstances, but
not others. In C++17, but not before (and not in C), the evaluation of
the expression "one" (and any side-effects) must come before the
evaluation of "two" for, amongst other things :

one << two
one >> two
one[two]
two = one

There is still /no/ ordering for

one * two
one + two

and many other cases.

And of course there are cases where there has always been a sequence
point, and therefore an order of evaluation (a logical order, that is -
if the compiler can see it makes no difference to the observable
effects, it can always re-arrange anything).

<https://en.cppreference.com/w/cpp/language/eval_order>
<https://en.cppreference.com/w/c/language/eval_order>

> This is so fundamental a construct and so frequently used that any
> compiler would have been withdrawn in the week after it came out.
> That is my expectation. So I would be grateful if you could provide
> some evidence that I can look up.

<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf>

For an example in practice, where you can see the generated assembly:

<https://www.godbolt.org/z/fWezzx1nd>

If I remember correctly, gcc 7 implemented the ordering rules from C++17
and back-ported them to previous C++ standards for user convenience (as
the order was previously unspecified, it was fine to do that).

Look at the generated assembly and the order in which the calls to
one(), two(), three() and four() are made. For the operator "<<", they
are made in order one() to four(). For the operator "+", and for
function call parameters, they are generated in order four() to one()
for this case. (In other cases, that may be different - that's what
"unspecified" means.)

>
> Mind that even if two() is evaluated before one(), it will not be
> output before the stream of the first expression op<<(cout, one())
> is available, and for this one() must be evaluated. Then one() can
> be sent to the stream, and then also two() can be sent to the stream.
> (Am I missing something?)

The output to the stream must be in the order given in the code - that
is true. But the values to be output could (prior to C++17) be
evaluated in any order. If one() and two() have side-effects, that is
critical - those side-effects could be executed in any order.

>
> Janis
>
>> and the rules changed in C++17.
>>
>> Usually it doesn't matter what order arguments to functions (or operands
>> to operators) are evaluated. Some compilers have consistent ordering
>> (and it is often last to first, not first to last), others pick whatever
>> makes sense at the time. The ordering has been explicitly and clearly
>> stated as "unspecified" since around the beginning of time (which was,
>> as we all know, 01.01.1970).
>
>

On 26/01/2024 13:17, Malcolm McLean wrote:

> We could say that in comp.lang.c "function" shall mean "a subroutine"

<snip the blather>

Why don't we just say - as everyone in this group except you already
says, that in c.l.c. "function" means "C function" as described in the C
standards, and any other type of function needs to be qualified?

Thus "the tan function" here means the function from <math.h>, not the
mathematical function, or something done when making leather.

It really is not difficult.

On 25/01/2024 16:26, Keith Thompson wrote:
> 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).
>

Fair enough. I think a lot of this kind of thing is just habit or
personal preference. There's always little differences in the way
people write their code.

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

Agreed. I don't think these details really make a big difference to
programming languages.

All what you wrote below targets at your last sentense
"those side-effects could be executed in any order".
For the examples we had, like (informally) cout<<a<<b<<c;
this is undisputed for the SIDE EFFECTS of "a", etc. You
had "hidden" those side effects in "one()", I gave in an
earlier post the more obvious example c++ in the context
of cout << c++ << c++ << c++ << endl; as side effects.
All side effects can be a problem (and should be avoided
unless "necessary"). My point was that the order of '<<'
with its arguments is NOT corrupted. I interpreted your
previous posting that you'd have heard that to be an issue.
If you haven't meant to say that there's nothing more to
say about the issue, since the other things you filled your
post with is only distracting from the point in question.

Janis

On 26.01.2024 17:01, David Brown wrote:
> On 26/01/2024 02:21, Janis Papanagnou wrote:
>> On 25.01.2024 21:11, David Brown wrote:
>>> On 25/01/2024 17:11, Janis Papanagnou wrote:
>
>>>> Is or was there any compiler that implemented that in the "unexpected"
>>>> order?
>>>>
>>>
>>> There were indeed such real-world cases, complaints were made,
>>
>> Complaints that the rule was not clear in its definition?
>> Or complaints that their compiler did not support cout<<a<<b<<c;
>> correctly? - I would be astonished about the latter.
>
> The pre-C++17 rule was perfectly clear - there was no specified order of
> execution for the operands. (And I thought I'd made /that/ perfectly
> clear already.) Compilers all worked correctly - they can hardly have
> fallen foul of a rule that did not exist.
>
> The complaints (at least, the ones based on facts rather than
> misunderstandings) were about the lack of a rule that enforced
> evaluation order in certain cases.
>
> So C++17 added rules for evaluation orders in some circumstances, but
> not others. In C++17, but not before (and not in C), the evaluation of
> the expression "one" (and any side-effects) must come before the
> evaluation of "two" for, amongst other things :
>
> one << two
> one >> two
> one[two]
> two = one
>
> There is still /no/ ordering for
>
> one * two
> one + two
>
> and many other cases.
>
> And of course there are cases where there has always been a sequence
> point, and therefore an order of evaluation (a logical order, that is -
> if the compiler can see it makes no difference to the observable
> effects, it can always re-arrange anything).
>
> <https://en.cppreference.com/w/cpp/language/eval_order>
> <https://en.cppreference.com/w/c/language/eval_order>
>
>
>> This is so fundamental a construct and so frequently used that any
>> compiler would have been withdrawn in the week after it came out.
>> That is my expectation. So I would be grateful if you could provide
>> some evidence that I can look up.
>
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf>
>
> For an example in practice, where you can see the generated assembly:
>
> <https://www.godbolt.org/z/fWezzx1nd>
>
> If I remember correctly, gcc 7 implemented the ordering rules from C++17
> and back-ported them to previous C++ standards for user convenience (as
> the order was previously unspecified, it was fine to do that).
>
> Look at the generated assembly and the order in which the calls to
> one(), two(), three() and four() are made. For the operator "<<", they
> are made in order one() to four(). For the operator "+", and for
> function call parameters, they are generated in order four() to one()
> for this case. (In other cases, that may be different - that's what
> "unspecified" means.)
>
>>
>> Mind that even if two() is evaluated before one(), it will not be
>> output before the stream of the first expression op<<(cout, one())
>> is available, and for this one() must be evaluated. Then one() can
>> be sent to the stream, and then also two() can be sent to the stream.
>> (Am I missing something?)
>
> The output to the stream must be in the order given in the code - that
> is true. But the values to be output could (prior to C++17) be
> evaluated in any order. If one() and two() have side-effects, that is
> critical - those side-effects could be executed in any order.
>
>>
>> Janis
>>
>>> and the rules changed in C++17.
>>>
>>> Usually it doesn't matter what order arguments to functions (or operands
>>> to operators) are evaluated. Some compilers have consistent ordering
>>> (and it is often last to first, not first to last), others pick whatever
>>> makes sense at the time. The ordering has been explicitly and clearly
>>> stated as "unspecified" since around the beginning of time (which was,
>>> as we all know, 01.01.1970).
>>
>>
>

On 26.01.2024 17:06, David Brown wrote:
> On 26/01/2024 13:17, Malcolm McLean wrote:
>
>> We could say that in comp.lang.c "function" shall mean "a subroutine"
>
> Why don't we just say - as everyone in this group except you already
> says, that in c.l.c. "function" means "C function" as described in the C
> standards, and any other type of function needs to be qualified?
>
> Thus "the tan function" here means the function from <math.h>, not the
> mathematical function, or something done when making leather.
>
> It really is not difficult.

Unless the discussion was done on a meta-level as opposed to a
concrete language specific implementation-model of a function,
or a concrete functions. - My impression from the posts upthread
was that we were taking on the meta-level to understand what we
actually have (with tha 'sizeof' beast) or how to consider it
conceptionally.

I also think that this is the key to not talk past each other.

The term "function" in computer science seems to have never been
an issue of dispute - I mean on a terminology level; explanations
in lectures or books were quite coherent, and since there was no
dispute everyone seems to have understood what a function is; in
computer science and in mathematics.

From my references it seems a consensus at least in that it's
reflecting a mathematical f: (x,y,...) -> (u,v,...) which is
projected at (or implemented by) some routine/procedure/method/
function, etc. - however it's called in any programming language.

The terminology certainly differs, but the interpretation less.

If we look deeper at the issue we can of course make academic
battles about other "function concepts" (my favorite example
is analogue computers; but that's extreme, of course). But in
that narrow corner we're discussing things it's sufficient IMO,
and probably more rewarding than restricting on the C function
implementation model.

How should we get principle insights on 'sizeof', what it is,
what it should be, etc., if we stay within this restricted C
world terminology, and discussing even a very special type of
a, umm.., function (sort of).

Janis

On 26/01/2024 18:31, Janis Papanagnou wrote:
> All what you wrote below targets at your last sentense
> "those side-effects could be executed in any order".
> For the examples we had, like (informally) cout<<a<<b<<c;
> this is undisputed for the SIDE EFFECTS of "a", etc. You
> had "hidden" those side effects in "one()", I gave in an
> earlier post the more obvious example c++ in the context
> of cout << c++ << c++ << c++ << endl; as side effects.
> All side effects can be a problem (and should be avoided
> unless "necessary"). My point was that the order of '<<'
> with its arguments is NOT corrupted. I interpreted your
> previous posting that you'd have heard that to be an issue.
> If you haven't meant to say that there's nothing more to
> say about the issue, since the other things you filled your
> post with is only distracting from the point in question.
>

I said - repeatedly - that the order of evaluation of the operands to
most operators is unspecified in C and C++. This could result in
behaviour that was unexpected for some people, especially in connection
with cout and other C++ streams, and was thus specified in C++17 for
specific cases.

A typical example would be :

cout << "Start time: " << get_time() << "\n"
<< "Running tests... " << run_tests() << "\n"
<< "End time: " << get_time();

It was realistic - and indeed happened in some cases - for pre-C++17
compilers to generate the second "get_time()" call before "run_tests()",
and finally do the first "get_time()" call. Alternatively, the compiler
could call "get_time()" twice, with "run_tests()" called either before
or after that pair. In all these cases, the user will see an output
that was not at all what they intended, with time appearing to go
backwards or the test apparently taking no time.

This was the case regardless of whether or not "get_time()" and
"run_tests()" had any side-effects.

You are, quite obviously, guaranteed that in "cout << a << b << c", the
output was in order a, b, c. But that is a totally different matter
from the order of evaluation (and execution, for function calls) of the
subexpressions a, b, and c.

I have said exactly what I intended to say in this thread, but I suspect
you have mistaken what the term "order of evaluation" means, and
therefore misunderstood what I wrote. I hope this is all clear to you now.

>
>
> On 26.01.2024 17:01, David Brown wrote:
>> On 26/01/2024 02:21, Janis Papanagnou wrote:
>>> On 25.01.2024 21:11, David Brown wrote:
>>>> On 25/01/2024 17:11, Janis Papanagnou wrote:
>>
>>>>> Is or was there any compiler that implemented that in the "unexpected"
>>>>> order?
>>>>>
>>>>
>>>> There were indeed such real-world cases, complaints were made,
>>>
>>> Complaints that the rule was not clear in its definition?
>>> Or complaints that their compiler did not support cout<<a<<b<<c;
>>> correctly? - I would be astonished about the latter.
>>
>> The pre-C++17 rule was perfectly clear - there was no specified order of
>> execution for the operands. (And I thought I'd made /that/ perfectly
>> clear already.) Compilers all worked correctly - they can hardly have
>> fallen foul of a rule that did not exist.
>>
>> The complaints (at least, the ones based on facts rather than
>> misunderstandings) were about the lack of a rule that enforced
>> evaluation order in certain cases.
>>
>> So C++17 added rules for evaluation orders in some circumstances, but
>> not others. In C++17, but not before (and not in C), the evaluation of
>> the expression "one" (and any side-effects) must come before the
>> evaluation of "two" for, amongst other things :
>>
>> one << two
>> one >> two
>> one[two]
>> two = one
>>
>> There is still /no/ ordering for
>>
>> one * two
>> one + two
>>
>> and many other cases.
>>
>> And of course there are cases where there has always been a sequence
>> point, and therefore an order of evaluation (a logical order, that is -
>> if the compiler can see it makes no difference to the observable
>> effects, it can always re-arrange anything).
>>
>> <https://en.cppreference.com/w/cpp/language/eval_order>
>> <https://en.cppreference.com/w/c/language/eval_order>
>>
>>
>>> This is so fundamental a construct and so frequently used that any
>>> compiler would have been withdrawn in the week after it came out.
>>> That is my expectation. So I would be grateful if you could provide
>>> some evidence that I can look up.
>>
>> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf>
>>
>> For an example in practice, where you can see the generated assembly:
>>
>> <https://www.godbolt.org/z/fWezzx1nd>
>>
>> If I remember correctly, gcc 7 implemented the ordering rules from C++17
>> and back-ported them to previous C++ standards for user convenience (as
>> the order was previously unspecified, it was fine to do that).
>>
>> Look at the generated assembly and the order in which the calls to
>> one(), two(), three() and four() are made. For the operator "<<", they
>> are made in order one() to four(). For the operator "+", and for
>> function call parameters, they are generated in order four() to one()
>> for this case. (In other cases, that may be different - that's what
>> "unspecified" means.)
>>
>>>
>>> Mind that even if two() is evaluated before one(), it will not be
>>> output before the stream of the first expression op<<(cout, one())
>>> is available, and for this one() must be evaluated. Then one() can
>>> be sent to the stream, and then also two() can be sent to the stream.
>>> (Am I missing something?)
>>
>> The output to the stream must be in the order given in the code - that
>> is true. But the values to be output could (prior to C++17) be
>> evaluated in any order. If one() and two() have side-effects, that is
>> critical - those side-effects could be executed in any order.
>>
>>>
>>> Janis
>>>
>>>> and the rules changed in C++17.
>>>>
>>>> Usually it doesn't matter what order arguments to functions (or operands
>>>> to operators) are evaluated. Some compilers have consistent ordering
>>>> (and it is often last to first, not first to last), others pick whatever
>>>> makes sense at the time. The ordering has been explicitly and clearly
>>>> stated as "unspecified" since around the beginning of time (which was,
>>>> as we all know, 01.01.1970).
>>>
>>>
>>
>

On 26/01/2024 18:59, Janis Papanagnou wrote:
> On 26.01.2024 17:06, David Brown wrote:
>> On 26/01/2024 13:17, Malcolm McLean wrote:
>>
>>> We could say that in comp.lang.c "function" shall mean "a subroutine"
>>
>> Why don't we just say - as everyone in this group except you already
>> says, that in c.l.c. "function" means "C function" as described in the C
>> standards, and any other type of function needs to be qualified?
>>
>> Thus "the tan function" here means the function from <math.h>, not the
>> mathematical function, or something done when making leather.
>>
>> It really is not difficult.
>
> Unless the discussion was done on a meta-level as opposed to a
> concrete language specific implementation-model of a function,
> or a concrete functions. - My impression from the posts upthread
> was that we were taking on the meta-level to understand what we
> actually have (with tha 'sizeof' beast) or how to consider it
> conceptionally.

We are - probably futilely - trying to get Malcolm to understand that
even in "meta-level" discussions, it is vital to be clear what is meant
by terms. And "function" alone means "C function" in c.l.c. You might
often think it is obvious from the context whether someone means "C
functions", "mathematical functions", or "wedding functions", but with
Malcolm you /never/ know. It regularly means "Malcolm functions", which
have an approximate definition that might change at any time.

>
> I also think that this is the key to not talk past each other.
>
> The term "function" in computer science seems to have never been
> an issue of dispute - I mean on a terminology level; explanations
> in lectures or books were quite coherent, and since there was no
> dispute everyone seems to have understood what a function is; in
> computer science and in mathematics.

The term "function" is most certainly in dispute in computer science.
It means different things - sometimes subtly, sometimes significantly -
in the context of different programming languages, or computation
theory, or mathematics. A "C function" is different from a "Pascal
function", a "lambda calculus function", a "Turing machine function", or
any other kind of function definition you want to pick.

>
> From my references it seems a consensus at least in that it's
> reflecting a mathematical f: (x,y,...) -> (u,v,...) which is
> projected at (or implemented by) some routine/procedure/method/
> function, etc. - however it's called in any programming language.

No, that is only one kind of function. There are all sorts of questions
to ask.

Can functions have side effects?

Do functions have to have outputs? Do they have to have inputs?

Does a function have to give the same output for the same inputs?

Can a function give more than one output? Does a function actually have
to be executed as called, or can the language re-arrange things?

Is it valid to have a function that does not satisfy certain
requirements, if that function is never called?

Can functions operate on types? Can they operate on other functions?
Can they operate on whole programs?

Does the function include some kind of data store? Does it include the
machine it executes on?

Does a function have to be executable? Does it even have to be
computable? Does it have to execute in a finite time?

Is a function a run-time entity, or a compile-time entity? Can it be
changed at run-time? Does it make sense to "run" a function at compile
time?

I'm sure we could go on.

>
> The terminology certainly differs, but the interpretation less.

The problem is that the terminology is the same, but the interpretation
can be wildly different. In order to communicate, we must be sure that
a given term is interpreted in the same way be each person.

>
> If we look deeper at the issue we can of course make academic
> battles about other "function concepts" (my favorite example
> is analogue computers; but that's extreme, of course). But in
> that narrow corner we're discussing things it's sufficient IMO,
> and probably more rewarding than restricting on the C function
> implementation model.

I think we're fine sticking to "function" meaning "C function", which is
well defined by the C standards, and using "mathematical function" for
mathematical functions, which are also quite solidly defined. Any other
usage will need to be explained at the time.

>
> How should we get principle insights on 'sizeof', what it is,
> what it should be, etc., if we stay within this restricted C
> world terminology, and discussing even a very special type of
> a, umm.., function (sort of).
>

Sizeof is not a C function. It is a C operator. If you don't know what
it is or how it works, or want the technical details, it's all in
6.5.3.4 of the C standards.

Trying to describe "sizeof" as a function of some sort with a different
kind of use of the word "function" really doesn't get us anywhere, as
shown in this thread. It is what it is - trying to mush it into another
term is not helpful.

David Brown <david.brown@hesbynett.no> writes:
[...]
> You are, quite obviously, guaranteed that in "cout << a << b << c",
> the output was in order a, b, c. But that is a totally different
> matter from the order of evaluation (and execution, for function
> calls) of the subexpressions a, b, and c.
[...]

Perhaps I can help clarify this a bit (or perhaps muddy the waters
even further). I'll try to add a bit of C relevance at the bottom.

In `cout << a << b << c`, if a, b, and c are names of non-volatile
objects, the evaluation order doesn't matter. The values of a, b,
and c will be written to the standard output stream in that order,
in all versions of C++.

In `cout << x() << y() << z()`, it's also guaranteed that the
result of the call to `x()` will precede the result of the call to
`y()`, which will precede the result of the call to `z()`, in the
text written to the output stream. What's not guaranteed prior
to C++17 is the order in which the three functions will be called.
If none of the functions have side effects that affect the results
of the other two, or depend on non-local data, it doesn't matter.
If the functions return, say, a string representation of the current
time with nanosecond resolution, the three results can be in any
of 6 orders prior to C++17; in C++17 and later, the timestamps will
always be in increasing order.

C++ overloads the "<<" shift operator for output operations, so each
"<<" after `std::cout` is really a function call, but the rules for
sequencing and order of evaluation are the same as for the built-in
"<<" integer shift operation. C++ could have imposed sequencing
requirements only on overloaded "<<" and ">> operators, but that
would have been more difficult to specify in the standard.

C++17 added a new requirement that the evaluation of the left
operand of "<<" or ">>" is "sequenced before" the right operand,
meaning that any side effects of the evaluation of the left operand
must be complete before evaluation of the right operand begins
(though optimizations that don't change the visible behavior are
still allowed). It did not add such a requirement for the "+"
operator, which is overloaded for std::string concatenation.

Here's an example:

#include <iostream>
#include <string>

static std::string func() {
static std::string results[] = {
"zero", "one", "two", "three", "four"
};
static int index = 0;
return results[index++];
}

int main() {
std::cout << func() << ' ' << func() << '\n';
std::string s = func() + ' ' + func() + '\n';
std::cout << s;
}

Prior to C++17, the first line of output could be either "zero one"
or "one zero", and the second could be either "two three" or
"three two". In C++17 and later, the first line of output must
be "zero one", but the second can still be either "two three" or
"three two" (I get different results with g++ and clang++).

(This raises some interesting questions about C++ I/O manipulators,
but I won't get into that here.)

The relevance to C is that a future C standard *could* impose new
sequencing requirements for some or all operators and for function
arguments, but without C++-style operator overloading there are
fewer contexts in which it would matter. If the operands of "+"
were sequenced, then `i++ + i++` would have defined behavior (it's
currently undefined).

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