On 26.01.2024 21:27, Keith Thompson wrote:
> 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++.

Please note that I used cout << a << b << c as a meta expression
to _subsume_ in one expression the two variants that may have possible
side effects; that with three functions, and that with three instances
of c++. I hoped that got clear from the subsequent text, but obviously
it confused the matter. Sorry about that.

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

Yes.

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

Okay.

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

This is actually what I was asking for; what they changed. Thanks.
(And as I suspected it's about "side effects of the evaluation".)

> [ snip example and prospect ]

And no, you haven't muddied the issue, au contraire, it's a very
clear presentation.

Janis

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

> "cout << one() << two() << three();"

Those C++ operators for I/O are a brain-dead idea. C-style printf formats
actually work better.

On Fri, 26 Jan 2024 15:59:11 +0100, David Brown wrote:

> On 25/01/2024 21:18, Lawrence D'Oliveiro wrote:
>
>> 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.

The default keys come from /usr/share/X11/locale/en_US.UTF-8/Compose,
which on my system contains something like 5000 entries.

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

Works fine for things like curly quotes “‘’”, em-dashes—, arithmetic
operators ×÷, some subscripts and superscripts ₉₂U²³⁹, arrows ←↑→↓.

I have a small number of entries in my .XCompose, because I don’t want to
have to remember too many customizations.

For less-commonly-used things, I go to an Emacs editor window and use its
ability to enter characters by their Unicode names, then copy and paste
from there.

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

The whole point about this example is that they do not need to “stand out
clearly”.

On 26.01.2024 19:59, David Brown wrote:
>
> I said - repeatedly - that the order of evaluation of the operands to
> most operators is unspecified in C and C++. [...]

Yes, and this was undisputed.

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

Yes, we have no differences.

And the sample is fine to show how we should NOT implement such time
measurements (or similar logic)!

A computer scientist or a sophisticated programmer would know that
there are run-times associated in such expressions:

cout << "S1" << f1() << "S2" << f2() << "S3" << f3();

t1 t2 t3 t4 t5 t6 t7 t8 t9

and he would act accordingly and serialize the expression (see below).

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

We disagree here; it may not appear so to you but get_time() actually
has a "side effect" (I put it in quotes, because it's literally no
"effect" but for the argument of its _sequencing problem_ it's a
relevant externality). It obtains (probably from a hardware device)
the time when the call happened.

That's why somewhat experienced programmers would not write above
code that way; something like "run_tests()" is (typically) or can be
very time consuming, so they'd do
t0 = get_time(); res = run_tests(); t1 = get_time();
cout << ... etc.

(Note: This argument implies NOT that a language shouldn't be made as
bulletproof as possible and sensible.)

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

(It was meant as a "meta expression". I've addressed that in my
response to Keith already; please see there.)

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

The order of evaluation of the '<<' was what I spoke about. The order
of the arguments had never been an issue. The "problem" with the order
of the arguments becomes a problem (without quotes) when side effects
of the arguments are inherent to the arguments.

You had been focused on the evaluation of the arguments (where side
effects might lead to unexpected behavior). I wasn't.

Janis

On 26.01.2024 22:16, Lawrence D'Oliveiro wrote:
> On Thu, 25 Jan 2024 14:07:25 +0100, David Brown wrote:
>
>> "cout << one() << two() << three();"
>
> Those C++ operators for I/O are a brain-dead idea. C-style printf formats
> actually work better.

Well, no. There's a reason for using operators. In OO design you define
classes, and you can define ostream operators << for your classes so
that you can use these like elementary types in an output stream. This
means you can output (and input) arbitrary complex classes. You'll also
get strong type-safety. And whatnot. Also the stream hierarchy offers
design and implementation paths that you just don't have with printf().

In case you haven't done OO design & programming there's unfortunately
not an easy way to explain or go into the necessary details here. I can
just suggest to get into that topic; it's worth, IMO.

The printf() method is quite old; with simple types it's a more compact
form of formula. You have some cryptic characters that shorten the
format string (whereas with C++ manipulators and other features you'll
have more flexibility, extensibility, but pay that with a bulkier form).

Janis

On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:

> On 26.01.2024 22:16, Lawrence D'Oliveiro wrote:
>> On Thu, 25 Jan 2024 14:07:25 +0100, David Brown wrote:
>>
>>> "cout << one() << two() << three();"
>>
>> Those C++ operators for I/O are a brain-dead idea. C-style printf
>> formats actually work better.
>
> Well, no. There's a reason for using operators.

But remember, you often need to do localized output. Which means parts of
a message may need to be reordered for grammatical purposes.

You can do this with printf, but not with C++ output operators.

On 26/01/2024 15:56, Keith Thompson wrote:
> 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)?
>
Yes, rand() is a Malcolm function but not a pure function.It's a
mathematical function which maps bits in memory on call to bits in
memory on return, and
has no other purpose. But because of the way those bits are scoped and
accessed,it is not "pure function".

"Pure functions" are a similar idea and getting at a similar thing to
what I want to talk about with Malcolm functions. But they aren't quite
the same thing. The general idea of isolating calculations from
manipulation of external peripherals is the same. But Malcolm functions
are more flexible and designed to match the way programmers actually
program rather than prescribe a more resticted way of programming.

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

On 26/01/2024 19:18, David Brown wrote:
> 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.
>
Basically I wanted "function" for C functions which are also
mathematical functions, and "procedure" for C functions which do not
meet the definition of mathematical functions. In context, of course.
And since this is normal, accepted usage, I though It would be accepted
here. But in fact people insisted on "Malcolm function" for a C function
which is also a mathematical function.
(Then of course you can get into "mathematical function of what?", and
"what is the function and what is the code that implements the
function". There is room for obtuseness and occasionally maybe genuine
confusion).

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>> On 26.01.2024 22:16, Lawrence D'Oliveiro wrote:
>>> On Thu, 25 Jan 2024 14:07:25 +0100, David Brown wrote:
>>>
>>>> "cout << one() << two() << three();"
>>>
>>> Those C++ operators for I/O are a brain-dead idea. C-style printf
>>> formats actually work better.
>>
>> Well, no. There's a reason for using operators.
>
> But remember, you often need to do localized output. Which means parts of
> a message may need to be reordered for grammatical purposes.
>
> You can do this with printf, but not with C++ output operators.

You can do this with POSIX printf.

POSIX specifies an extension to printf that allows arguments to be
re-ordered. For example:
printf("%2$s%1$s\n", "foo", "bar");
prints "barfoo".

ISO C does not have this feature.

Another way to reorder arguments is to construct a string and then print
it. (String manipulation can be easier in C++ than in C, but that's a
side issue.)

C++'s `cout << ...` has advantages and disadvantages. It's much more
type-safe than printf, something that's possible only because of C++'s
operator overloading. I can print something without first looking up
its type and then determining what format string I need to specify that
type.

--
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 Fri, 26 Jan 2024 15:41:43 -0800, Keith Thompson wrote:

> You can do this with POSIX printf.
>
> POSIX specifies an extension to printf that allows arguments to be
> re-ordered. For example:
> printf("%2$s%1$s\n", "foo", "bar");
> prints "barfoo".
>
> ISO C does not have this feature.

I often feel, reading the complaints about deficiencies in this group,
that C does not work very well unless it is running on top of a *nix-type
system.

> C++'s `cout << ...` has advantages and disadvantages.

Interesting about Java, with all its needless complexity and futile
attempts at simplification, that this was one decision it made correctly,
and that was not to copy those operators.

On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:

> Also the stream hierarchy offers
> design and implementation paths that you just don't have with printf().

And that you don’t need, frankly. Java manages just fine with printf-style
formatting and “toString()” methods.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Basically I wanted "function" for C functions which are also
> mathematical functions, and "procedure" for C functions which do not
> meet the definition of mathematical functions. In context, of
> course. And since this is normal, accepted usage, I though It would be
> accepted here.

No, it's not "normal, accepted usage" in the context of C.

[...]

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

On 26.01.2024 20:18, David Brown wrote:
> 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 don't like the habit of introducing personalized terms like
"Malcolm functions"; this habit exposes more of the person who
introduced it than anything else. And it anyway would only muddy
the issue not clarify.)

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

We have to divide et impera the area for the discussion to not
get into the wild. The first divide is the abstraction level;
this is what I've done below. (Because any technical differences
of every single computer language makes no sense in a discussion
on a higher abstraction level. - I see no use in differentiating
Pascal functions from Simula or Algol functions for the discussion
here.)

(I fear this thread will lead nowhere, but okay, I'll enter...)

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

What relevance has any technical difference of "C functions"
and "Pascal functions"? - None.

What do you think is the difference between a function from
the lambda-calculus and a function from/for Turing Machines
concerning the class of functions that can be expressed and
calculated respectively? And in what way would syntax of any
of these two languages contribute to the question? - Nothing.

Note: I don't want you to answer these questions. I suppose
you might have some substantial CS background (I certainly do)
and are not just spreading buzzwords.
Neither the technical (implementation) differences of the first
two types are relevant for the topics that have been discussed,
nor the algorithm theory definitions of the latter two function
types are relevant here.

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

That is an abstract representation from mathematics (and I am
not interest in syntactic differences to other forms) that can
be directly mapped to an algorithmic representation.

We write (for example [borrowed from a book]):

f: R x R x R -> R for the domains; R here: real numbers

f(r,R,h) -> pi/3 x h x (r^2 + r x R + R^2)

and in computer languages (for example) syntactic variants of:

f = (real r, real R, real h) real :
pi/3 * h * (r^2 + r * R + R^2)

The function from the language closely resembles that from the
mathematic domain.

This is an Algol(-like) syntax representation, other languages
have other syntaxes but mostly it boils down to few differences.

It's not really important for our discussions to consider Algol's
ref, Pascal's var, C++'s const, or what else. For the sake of the
discussion upthread it's also irrelevant whether we have parameters
passed by value, by reference, by name, or consider some deep or
shallow copy mechanisms, and it's also not necessary to know for
this discussions whether the caller or the called instance will
allocate the stack size, or whether there's stack at all allocated.
There's countless _technical_ differences that are meaningless in
a taxonomy-like discussion here.

> There are all sorts of questions to ask.

Yes, but not many (none?) of significance in our discussion context
here.

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

(Yes, and it wouldn't add anything.)

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

Yes. But remember that our question was not a technical one; wasn't
the question by the other poster (Malcolm?) about a mathematical
function term and how it fits to determine what 'sizeof' actually is
to be considered.

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

I know it's an operator in C. And I also wasn't saying that it's a
C function. - You still see the "(sort of)" in my statement. And we
already spoke about the close (but not exact) equivalences between
functions and operators.

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

On 27.01.2024 00:51, Lawrence D'Oliveiro wrote:
> On Fri, 26 Jan 2024 15:41:43 -0800, Keith Thompson wrote:
>> C++'s `cout << ...` has advantages and disadvantages.
>
> Interesting about Java, with all its needless complexity and futile
> attempts at simplification, that this was one decision it made correctly,
> and that was not to copy those operators.

Chosing these operators is a separate issue. But, yes. With the
operator precedence borrowed from the shift operator you need to
be careful. As part of the output operator syntax I'd expected
a precedence like '=' or even lower.

Janis

On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>
>> Also the stream hierarchy offers
>> design and implementation paths that you just don't have with printf().
>
> And that you don’t need, frankly.

Don't be so fast with your judgment. Of course we use it to elegantly
and scaleably solve tasks in C++.

> Java manages just fine with printf-style formatting and “toString()” methods.

I tried to explain in my other post that it's not just about a format
(or a string-sequencing member function). But I'm sure one must be
deeper in the topic or have experienced (besides any supposed issues)
the sophisticated possibilities that C++ offers to support good design.

Java (as a newer language) has also some advantages, but was in many
respects far behind C++ (IMO). ("was" because I lately didn't follow
its evolution any more.) - But that's anyway all off-topic here.

Janis

On Sat, 27 Jan 2024 01:27:55 +0100, Janis Papanagnou wrote:

> On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>
>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>
>>> Also the stream hierarchy offers design and implementation paths that
>>> you just don't have with printf().
>>
>> And that you don’t need, frankly.
>
> Don't be so fast with your judgment. Of course we use it to elegantly
> and scaleably solve tasks in C++.

But not localization, which is an important issue. printf-style formatting
allows rearrangement of parts of a message to suit grammar purposes, C++-
style output operators do not.

> Java (as a newer language) has also some advantages, but was in many
> respects far behind C++ (IMO).

It made many mistakes. The goal of trying to be simpler than C++ was I
think a failure.

On 27/01/2024 00:27, Janis Papanagnou wrote:

> Java ...C++ ..
> But that's anyway all off-topic here.

JP finally realises that, after 100 posts of ramblings about anything but C.

From 'bart cc32n.c' thread:

JP:
>No, you are wrong, I'm not the owner of this piece of... code.

>If someone makes a big heap of fecal in a public park, would
>you think I'm the owner? I'd rather sue the one who did that;
>because the park (or Usenet) is common property, and the heap
>of fecal (or that code) is not.

What a thoroughly unpleasant piece of work.

On 1/26/24 12: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 effect

There's an important reason why he used one(), two(), and three().
"If a side effect on a memory location (6.7.1) is unsequenced relative
to either another side effect on the same memory location or a value
computation using the value of any object in the same memory location,
and they are not potentially concurrent (6.9.2), the behavior is
undefined." (C++ 6.9.1p10)

"Two actions are potentially concurrent if
(21.1)— they are performed by different threads, or
(21.2)— they are unsequenced, at least one is performed by a signal
handler, and they are not both performed
by the same signal handler invocation." (C++ 6.9.2.1p21)

So the exception for potentially concurrent side effects cannot apply to
your version.

All three of your c++ expressions have side effects on the same memory
location, and all use the value stored in that location. Prior to the
change which is being discussed, all three of those side effects would
have been unsequenced from each other and from each other's value
computations, so the behavior of such an expression would have been
undefined. With this change, they are sequenced, and there is no longer
a problem with such code.

The function one(), two() and three() that he used could have side
effects that effect each other without sharing a memory location, for
instance by writing to and reading from a file. Therefore, such code
would have worked both before and after that change - but it might have
given different results before the change.

> All side effects can be a problem (and should be avoided
> unless "necessary").

Virtually everything useful that a computer program does qualifies as a
side effect. Side effects cannot be avoided, they can only be controlled.

On 1/26/24 16:30, Janis Papanagnou wrote:
....
> We disagree here; it may not appear so to you but get_time() actually
> has a "side effect" (I put it in quotes, because it's literally no
> "effect" but for the argument of its _sequencing problem_ it's a
> relevant externality). It obtains (probably from a hardware device)
> the time when the call happened.

"Reading an object designated by a volatile glvalue (7.2.1), modifying
an object, calling a library I/O function, or calling a function that
does any of those operations are all side effects, which are changes in
the state of the execution environment." (C++ 6.9.1p7)

The term "side effect" is in italics in that sentence, an ISO convention
indicating that the sentence in which it appears constitutes the
official definition of that term. Everything that the C++ standard says
about side effects traces back to that definition.

On 1/26/24 19:12, Janis Papanagnou wrote:
> On 26.01.2024 20:18, David Brown wrote:
....
> (I don't like the habit of introducing personalized terms like
> "Malcolm functions"; this habit exposes more of the person who
> introduced it than anything else. And it anyway would only muddy
> the issue not clarify.)

It is an unfortunate necessity when talking with Malcolm. He has his own
idiosyncratic definitions for just about any technical term you care to
name, which he generally believes to be universally accepted, when he
appears to be the only person using those words with those definitions.

....
>> 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.
>
> What relevance has any technical difference of "C functions"
> and "Pascal functions"? - None.

The fact that there are differences between the meanings of each of
those terms is relevant to the fact that you need to be clear which of
those terms you are using. Given that this is comp.lang.c, the one
exception is "C function", which can be assumed whenever no other kind
of function is specified.

....
> It's not really important for our discussions to consider Algol's
> ref, Pascal's var, C++'s const, or what else.

You might think so, but it's not uncommon fro those things to come up in
discussion here. It's particularly common for critics of C to discuss
their preferred alternative.

....
> Yes. But remember that our question was not a technical one; wasn't
> the question by the other poster (Malcolm?) about a mathematical
> function term and how it fits to determine what 'sizeof' actually is
> to be considered.

As you'll find if you stay here long enough, every discussion involving
Malcolm degenerates into confusion until someone realizes that he's
using a Malcolm-definition for one or more of the relevant terms. It's
not possible to make sense of his comments until you've extracted from
him his idiosyncratic definitions for those terms.

On 27/01/2024 00:12, Janis Papanagnou wrote:
>
> (I don't like the habit of introducing personalized terms like
> "Malcolm functions"; this habit exposes more of the person who
> introduced it than anything else. And it anyway would only muddy
> the issue not clarify.)
>
It was insisted upon. A C function which is also a mathematical function
is to be called a "Malcolm function". Personally I wanted just
"function" and for it to be clear from context that here the term did
not mean "subroutine".

By separating out the Malcolm functions from the non-Malcolm functions
in the code, we can achieve some very interesting and highly desireable
advantages.

But there are a few edge cases, especially functions which would be
clearly Malcolm functions, but can accept pointers to functions which
are not Malcolm functions. So there are things to talk a bit and, as
others have pointed out, the act of settling on a special term means
that it can now be defined.

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

On 26/01/2024 23:52, Lawrence D'Oliveiro wrote:
> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>
>> Also the stream hierarchy offers
>> design and implementation paths that you just don't have with printf().
>
> And that you don’t need, frankly. Java manages just fine with printf-style
> formatting and “toString()” methods.
>
The problem is that the stream hierarchy both serialises (puts data into
a form with no hierarchy which can be stored in raw memory or in backing
store), and creates human readable output. Whilst to an extent you can
do both at the same time, the goals are different.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 27/01/2024 00:42, bart wrote:
> On 27/01/2024 00:27, Janis Papanagnou wrote:
>
>> Java ...C++ ..
>> But that's anyway all off-topic here.
>
> JP finally realises that, after 100 posts of ramblings about anything
> but C.
>
>
> From 'bart cc32n.c' thread:
>
> JP:
> >No, you are wrong, I'm not the owner of this piece of... code.
>
> >If someone makes a big heap of fecal in a public park, would
> >you think I'm the owner? I'd rather sue the one who did that;
> >because the park (or Usenet) is common property, and the heap
> >of fecal (or that code) is not.
>
> What a thoroughly unpleasant piece of work.
>
Yes, it's not nice. It's hard to make software go viral and it isn't
something I have achieved myself, despite quite a bit of trying. But
the reason is not always that the code is inherently worthless.

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

On 26/01/2024 21:46, Janis Papanagnou wrote:
> On 26.01.2024 22:16, Lawrence D'Oliveiro wrote:
>> On Thu, 25 Jan 2024 14:07:25 +0100, David Brown wrote:
>>
>>> "cout << one() << two() << three();"
>>
>> Those C++ operators for I/O are a brain-dead idea. C-style printf formats
>> actually work better.
>
> Well, no. There's a reason for using operators. In OO design you define
> classes, and you can define ostream operators << for your classes so
> that you can use these like elementary types in an output stream. This
> means you can output (and input) arbitrary complex classes. You'll also
> get strong type-safety. And whatnot. Also the stream hierarchy offers
> design and implementation paths that you just don't have with printf().
>
> In case you haven't done OO design & programming there's unfortunately
> not an easy way to explain or go into the necessary details here. I can
> just suggest to get into that topic; it's worth, IMO.
>
> The printf() method is quite old; with simple types it's a more compact
> form of formula. You have some cryptic characters that shorten the
> format string (whereas with C++ manipulators and other features you'll
> have more flexibility, extensibility, but pay that with a bulkier form).
>
It's hard to think of anything that can be passed to standard outut
other than integers, floating point values, and strings. So you only
need three atomic operations.
You can then buld complex objects consisting of integers, floats and
strings on top of those three basic operations. But the stream itself
should be locked down and not open to derivation.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 27.01.2024 01:38, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 01:27:55 +0100, Janis Papanagnou wrote:
>
>> On 27.01.2024 00:52, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 26 Jan 2024 22:46:25 +0100, Janis Papanagnou wrote:
>>>
>>>> Also the stream hierarchy offers design and implementation paths that
>>>> you just don't have with printf().
>>>
>>> And that you don’t need, frankly.
>>
>> Don't be so fast with your judgment. Of course we use it to elegantly
>> and scaleably solve tasks in C++.
>
> But not localization, which is an important issue. printf-style formatting
> allows rearrangement of parts of a message to suit grammar purposes, C++-
> style output operators do not.

I see where you're coming from. Myself I have just cursory knowledge
about and experience in localization, so I have no strong opinions
on that and thus cannot and don't want to work into the details.
What I [think to] know is that simple word permutations don't help
for general cases of localization, so printf would just work for
some primitive application special cases. (But feel free to CMIIW.)
Other languages don't operate on simple word arrangements but on whole
sentences. In Kornshell, for example, you can predefine language
strings (in "dictionaries") to be incorporated for displaying language
specific messages. This is a simple and effective mechanism, and I
have difficulties to imagine how printf with its parameter permutation
would create flexible and clean localization; I'd expect a mess (but,
to be honest, haven't yet seen any convincing example). C++ has also
localization support, but as said I have no experience with it. For
more complex language manipulations you'd anyway need more than word
permutation.

I used to play intensively Nethack; it's a roguelike game known for
creating well formulated (English) sentences. The source code has a
lot of code to handle manipulation of language for various details
of the grammar; plural forms, forms for cases, and whatnot. Someone
wanted to migrate the game (with its grammar functions) to another
language; it was very difficult and could not be achieved by simple
mechanisms like word permutation and word substitution, IIRC.

>
>> Java (as a newer language) has also some advantages, but was in many
>> respects far behind C++ (IMO).
>
> It made many mistakes. The goal of trying to be simpler than C++ was I
> think a failure.

Well, personally I prefer "simple" languages to complex ones. (Oh,
well, yet I like C++.) Okay, by simple I mean coherently defined
with clean concepts. Though I wouldn't call Java simpler than C++;
for example the STL was much more sophisticated and orthogonally
designed (thus in this respect simpler) where the Java libraries
looked more like an ad hoc tool chest (like in Javascript or PHP).
But when I saw later C++ evolutions (was it C++/2011 ?) I can just
admit that at least now it became an overly complex language.

Janis