On 28/01/2024 21:40, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 12:35:00 +0100, David Brown wrote:
>
>> On 27/01/2024 21:49, Lawrence D'Oliveiro wrote:
>>
>>> The dirty little secret of pure-functional programming is that I/O
>>> cannot be treated in a purely functional fashion.
>>
>> It can - you just have to have the IO world as an input and an output to
>> your function.
>
> You mean, carry around multiple copies of the entire Universe in
> individual variables?

No, you only need one copy at a time :-) And you only actually need a
bit of the universe, covering your input and output streams.

Another option is that your code does not actually do any IO, but
returns a function that can be applied to the world to give the results
you want.

Real functional programming languages have smarter ways of doing this in
an efficient way. The functions may be pure as you see them in code,
but the generated results do IO just like any other generated code in
other languages. This gives you the advantages of purity at the source
level - it's far easier to have mathematical proofs of the code's
correctness, multi-threading or asynchronous coding is easy because you
have no state, therefore no shared state, therefore no race conditions.
But the end result is efficient - perhaps not "well-written C"
efficient, but close enough to be of practical use in the real world.
The key challenge is that you have to understand monads!

A much simpler idea in a similar vein is that functional programming
languages don't have iterative loops - you use lists or recursion to
express repetition. In C, having a recursive function that works
through a linked list is massively inefficient compared to a for loop,
in both run-time and stack space. In a functional programming language,
lists and recursion make it simple and clear to express the code - and
the compiler turns it all into an iterative loop in the generated code.

(Facebook uses Haskell for their filters and other data handling. You
may not think much about Facebook's algorithms, but it shows that pure
functional programming works fine and efficiently for big IO
applications. Major mobile phone systems are programmed in Erlang,
which is a functional programming language, albeit an impure one which
can "cheat".)

On 28/01/2024 21:43, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 12:53:36 +0100, David Brown wrote:
>
>> On 27/01/2024 21:59, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 27 Jan 2024 17:26:24 GMT, Scott Lurndal wrote:
>>>
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>> Standard printf formatting also does not allow such re-arrangements.
>>>>>
>>>> Depends on what standard you use. POSIX certainly does.
>>>
>>> C and POSIX go together like a horse and carriage; one without the
>>> other is a lot less useful.
>>
>> To the nearest percent, 0% of all systems running C programs support
>> POSIX (or Windows, or any other "big" system). The world of small
>> embedded systems totally outweigh "big" systems by many orders of
>> magnitude. And perhaps 80% of such small systems are programmed in C.
>
> And a lot of those “embedded” systems are running Android.

No, they are not. Android is Linux, and is included in the 0%.

>
> Android ships as many units per year as the entire installed base of
> Microsoft Windows.

Sure. And it is still within the 0%.

Take your car as an example. There's a reasonable chance, if it is
modern, that the entertainment and navigation system is running Android.
You might have a couple of other parts running embedded Linux of other
types. And you might have 100 other microcontrollers running programs
written in C, but not running a "big" POSIX OS. Some will run RTOS's,
some will be bare metal.

On the computer on your desk, you have a microcontroller in your mouse,
keyboard, webcam, screen, harddisk, managed switch. Your printer might
have some kind of embedded Linux for its display and UI, but probably
has many other microcontrollers in it. Your toaster, oven, fridge,
alarm clock, digital thermometer - microcontrollers are everywhere.

Even your typical Android device - a phone or tablet - will have a few
separate microcontrollers, and a variety of bits and pieces in its SoC
that are programmed in C but do not have a POSIX system.

On 28/01/2024 20:14, Janis Papanagnou wrote:
> On 27.01.2024 16:43, David Brown wrote:
>> On 26/01/2024 22:30, Janis Papanagnou wrote:

>>
>>> 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.
>>
>> Of course.
>
> You can serialize (as I suggested previously as one example) or
> embed functions like take_time(run_tests()) as another example.
>
>>
>> In practice, they could still be badly wrong even with that code -
>> there's a lot of subtle points to consider when trying to time code, and
>> my experience is that very few programmers get it entirely right.
>
> Really? - I mostly had to do with folks, even newbies with a
> proper CS education, who had enough experience or knowledge.
> Most problems appeared in contexts where the used languages
> have inherent design issues; not in any case we could avoid
> use of such languages in the first place.
>

Let's suppose you have a "get_time()" function that gets a time stamp
from somewhere, and that it correctly uses a volatile access from
hardware (or some OS-controlled time function that is volatile
somewhere). And suppose you are trying to time a function to test the
speed of recursion on your system :

unsigned int factorial(unsigned int x) {
if (x == 0) return 1;
return x * factorial(x - 1);
}

What happens when you write this? :

unsigned int x = 10;
double start = get_time();
unsigned int y = factorial(x);
double end = get_time();

printf("Time is %f seconds\n", end - start);

It looks reasonable enough, and because "get_time()" has observable
behaviour (a volatile access), it must be correct, right? It gives
shows a small but non-zero time, as expected.

But what you have actually measured is the overhead in the get_time()
function, because the compiler has removed the call to factorial because
the answer is not needed.

So you try :

unsigned int x = 10;
double pre_start = get_time();
double start = get_time();
unsigned int y = factorial(x);
double end = get_time();

double overhead = start - pre_start;
printf("Factorial %ui is %ui\n", x, y);
printf("Time is %f seconds\n", end - start - overhead);

to compensate for the overhead in the timing, and to force the compiler
to run factorial(10) because you observe its output. Now you get the
right answer for y, and the time is 0, because the compiler has
pre-calculated factorial x and substituted 3628800 for y.

So you take "x" from argv, so that the compiler can't pre-calculate the
result. And now the time is 0, because the compiler has re-arranged the
code as though it was :

unsigned int x = atoi(argv[1]);
double pre_start = get_time();
double start = get_time();
double end = get_time();

double overhead = start - pre_start;

unsigned int y = factorial(x);
printf("Factorial %ui is %ui\n", x, y);
printf("Time is %f seconds\n", end - start - overhead);

Making x and y both volatile gives you a time for the call to
factorial(x). It is still not measuring any recursion speed, because
the compiler has turned that function into a loop.

And that is before we start asking if you are measuring the speed of the
code, or of the memory and cache system on your PC.

I regularly see people failing to time or benchmark functions as they
expect - they don't understand how the compiler can re-arrange or
optimise things. A recurring problem is the belief that volatile
accesses force an order on other memory accesses, or on calculations,
which is not correct.

Then they decide to disable optimisation because "the optimiser messes
with my timing code", getting a result as useful as measuring the speed
of a race car stuck in first gear.

On 29/01/2024 01:03, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 14:49:53 -0800, Keith Thompson wrote:
>
>> A lot (for some interpretations of "a lot") of embedded systems run
>> Android. Those aren't the one David was talking about.
>
> They have a POSIX-type C runtime. Which does support “%«n»$” for
> reordering args to the printf routines.
>
> The point being the prevalence of POSIX is a little larger than you give
> it credit for.

No, it is not. I doubt if there are many people here that don't know
that Android is Linux, and therefore POSIX, or that there are lots more
Android systems than Windows systems. If you exclude obvious cases like
phones, tablets, and smart TVs, there are many more embedded Linux
systems that are not Android, than embedded Android systems. Those are
all POSIX too. And yet they are all part of the 0%.

Now, it is not uncommon for the libraries of small embedded systems to
support some POSIX extensions - the "newlib" family of C libraries
supports POSIX extensions to printf formatting flags, such as control of
positional arguments. But many other embedded C libraries do not. And
support for that one extension does not imply POSIX support or
"POSIX-type C runtime" libraries.

On 29/01/2024 03:17, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 17:48:53 -0800, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> The point being the prevalence of POSIX is a little larger than you
>>> give it credit for.
>>
>> Again, David wasn't talking about Android systems.
>
> No, I was, as an example of the sort of POSIX system he thought was too
> minuscule to worry about.

I think your mind-reading equipment needs adjustment. Perhaps I should
take off my tin-foil hat - would that make it easier for you to argue
against what you imagine I think?

On 28/01/2024 20:49, Malcolm McLean wrote:
> On 28/01/2024 18:24, David Brown wrote:
>> On 28/01/2024 17:09, Malcolm McLean wrote:

>>> You put non-ASCII text on stdout?
>>> I mean, obviously in a program for international use itself. But in
>>> routine program for general use?
>>>
>>
>> I commonly write out in UTF-8 - it does not have to be
>> "international". (I assume that by "international" you, as a good
>> Brit, mean "not UK". After all, a program written solely for use in
>> Norwegian is not international.)
>>
> I'd expect that most general purpose programs written by Norwegians use
> an English interface, even if it isn't really expected that the program
> will find an audience beyond some users in Norway. Except of course for
> programs which in some way are about Norway.

Why?

I might write the program with English output if the output language
doesn't matter, because I am lazy and write better English than
Norwegian. I might give it English output if the program were to be
used in a context where English is prevalent already, such as a
programming utility. But if it is intended to be used by Norwegians in
general use, I'll make the output in Norwegian.

Just because Norwegians are, for the most part, very good at English,
does not mean they don't prefer Norwegian.

> >
>> Sometimes I will have binary data of some kind on the standard output.
>> It's a lot less common, but it happens.  A common example would be
>> code for generating images or other files for a webserver.
>>
>> Most of my "real" programs, rather than small utilities, are for
>> embedded systems where the concept of "standard output" is not really
>> the same as for PC's.
>>
> I've never used standard output for binary data. It might be necessary
> for webservers that serve images. But it strikes me as a poor design
> decision.

It's simply something you haven't considered. Don't assume that the
kind of programming /you/ do, or that /you/ have experience with, is in
any way representative of other kinds of programming needs or practices.

On 28/01/2024 20:16, Janis Papanagnou wrote:
> On 27.01.2024 17:46, David Brown wrote:
>> [...]
>
> FYI: Too long to read at the moment. (Maybe later, maybe not.)
>

OK. It's off-topic, and just chatter, so if you don't reply I will not
feel insulted :-)

On 29/01/2024 12:35, David Brown wrote:
> On 28/01/2024 21:43, Lawrence D'Oliveiro wrote:
>> On Sun, 28 Jan 2024 12:53:36 +0100, David Brown wrote:
>>
>>> On 27/01/2024 21:59, Lawrence D'Oliveiro wrote:
>>>
>>>> On Sat, 27 Jan 2024 17:26:24 GMT, Scott Lurndal wrote:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>
>>>>>> Standard printf formatting also does not allow such re-arrangements.
>>>>>>
>>>>> Depends on what standard you use.  POSIX certainly does.
>>>>
>>>> C and POSIX go together like a horse and carriage; one without the
>>>> other is a lot less useful.
>>>
>>> To the nearest percent, 0% of all systems running C programs support
>>> POSIX (or Windows, or any other "big" system).  The world of small
>>> embedded systems totally outweigh "big" systems by many orders of
>>> magnitude.  And perhaps 80% of such small systems are programmed in C.
>>
>> And a lot of those “embedded” systems are running Android.
>
> No, they are not.  Android is Linux, and is included in the 0%.
>
>>
>> Android ships as many units per year as the entire installed base of
>> Microsoft Windows.
>
> Sure.  And it is still within the 0%.
>
> Take your car as an example.  There's a reasonable chance, if it is
> modern, that the entertainment and navigation system is running Android.
>  You might have a couple of other parts running embedded Linux of other
> types.  And you might have 100 other microcontrollers running programs
> written in C, but not running a "big" POSIX OS.  Some will run RTOS's,
> some will be bare metal.
>
> On the computer on your desk, you have a microcontroller in your mouse,
> keyboard, webcam, screen, harddisk, managed switch.  Your printer might
> have some kind of embedded Linux for its display and UI, but probably
> has many other microcontrollers in it.  Your toaster, oven, fridge,
> alarm clock, digital thermometer - microcontrollers are everywhere.

I think this is being disingenuous. Of course there are countless
millions of integrated circuits used everywhere, that will outnumber the
packaged consumer devices that everyone knows about.

Some of them may have programmable elements. But, no matter how crude,
how limited, if somebody, somewhere, has configured a program to turn a
subset of C into code for that device, that enables you to add that to
the list of systems you claim are programmed in 'C'.

Even if it relies on dedicated extensions or uses lots of inline assembly.

> Even your typical Android device - a phone or tablet - will have a few
> separate microcontrollers, and a variety of bits and pieces in its SoC
> that are programmed in C but do not have a POSIX system.
>

Maybe you can count each main CPU and each core separately too!

On 1/28/24 18:00, Keith Thompson wrote:
....
> And in environments like POSIX that don't distinguish between text and
> binary output streams, it can be perfectly sensible (though not 100%
> portable) to send binary data to stdout.

I'm sure you know about the following, but for Malcolm's benefit, I want
to expand on that comment. In other environments, the fact that stdout
is initially a text stream means that freopen() would have to be used to
change it to a binary stream - but it is otherwise no more of a problem
than in a POSIX environment.

On 29/01/2024 17:23, bart wrote:
> On 29/01/2024 12:35, David Brown wrote:
>> On 28/01/2024 21:43, Lawrence D'Oliveiro wrote:
>>> On Sun, 28 Jan 2024 12:53:36 +0100, David Brown wrote:
>>>
>>>> On 27/01/2024 21:59, Lawrence D'Oliveiro wrote:
>>>>
>>>>> On Sat, 27 Jan 2024 17:26:24 GMT, Scott Lurndal wrote:
>>>>>
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>>
>>>>>>> Standard printf formatting also does not allow such re-arrangements.
>>>>>>>
>>>>>> Depends on what standard you use.  POSIX certainly does.
>>>>>
>>>>> C and POSIX go together like a horse and carriage; one without the
>>>>> other is a lot less useful.
>>>>
>>>> To the nearest percent, 0% of all systems running C programs support
>>>> POSIX (or Windows, or any other "big" system).  The world of small
>>>> embedded systems totally outweigh "big" systems by many orders of
>>>> magnitude.  And perhaps 80% of such small systems are programmed in C.
>>>
>>> And a lot of those “embedded” systems are running Android.
>>
>> No, they are not.  Android is Linux, and is included in the 0%.
>>
>>>
>>> Android ships as many units per year as the entire installed base of
>>> Microsoft Windows.
>>
>> Sure.  And it is still within the 0%.
>>
>> Take your car as an example.  There's a reasonable chance, if it is
>> modern, that the entertainment and navigation system is running
>> Android.   You might have a couple of other parts running embedded
>> Linux of other types.  And you might have 100 other microcontrollers
>> running programs written in C, but not running a "big" POSIX OS.  Some
>> will run RTOS's, some will be bare metal.
>>
>> On the computer on your desk, you have a microcontroller in your
>> mouse, keyboard, webcam, screen, harddisk, managed switch.  Your
>> printer might have some kind of embedded Linux for its display and UI,
>> but probably has many other microcontrollers in it.  Your toaster,
>> oven, fridge, alarm clock, digital thermometer - microcontrollers are
>> everywhere.
>
> I think this is being disingenuous. Of course there are countless
> millions of integrated circuits used everywhere, that will outnumber the
> packaged consumer devices that everyone knows about.
>
> Some of them may have programmable elements. But, no matter how crude,
> how limited, if somebody, somewhere, has configured a program to turn a
> subset of C into code for that device, that enables you to add that to
> the list of systems you claim are programmed in 'C'.

I am talking about systems with CPUs of some sort that are regularly
programmed in C. I am not including chips that just have configuration,
or 4-bit devices that are programmed in their own Forth-like assembly.

>
> Even if it relies on dedicated extensions or uses lots of inline assembly.
>

Sure. I am not suggesting that these devices are programmed /solely/ in
C - certainly not solely in standard and portable C. But then, few
programs on PC's or other "big" systems are programmed solely in pure
standard C.

And I am not restricting this to devices that the end user can program
in C. Most devices cannot be accessed or re-programmed by the end-user
- some cannot be reprogrammed at all, with the program in ROM of some kind.

>> Even your typical Android device - a phone or tablet - will have a few
>> separate microcontrollers, and a variety of bits and pieces in its SoC
>> that are programmed in C but do not have a POSIX system.
>>
>
> Maybe you can count each main CPU and each core separately too!

That would change the dynamics a bit, but it would not change the
overall point.

On 27/01/2024 11:36, Janis Papanagnou wrote:
> On 27.01.2024 12:02, Malcolm McLean wrote:
>> On 27/01/2024 10:34, Janis Papanagnou wrote:
>>> On 27.01.2024 04:05, Malcolm McLean wrote:
>>>> [...] Personally I wanted just
>>>> "function" and for it to be clear from context that here the term did
>>>> not mean "subroutine".
>>>
>>> In my book; there's the "concept function" (mathematical), and the
>>> mapping/implementation onto/in a computer (a "calculation routine").
>>> The latter has just different names in different languages and it
>>> naturally has different technical details. In any form its purpose
>>> is to be an implemented instance of a formal mathematical concept.
>>>
>>> Janis
>>>
>>
>> I don't really see how "Bleep" is any sort of mathematical function. But
>> it is clearly a "subroutine".
>
> I don't know what that 'Bleep' is that you mention here, but I suppose
> that is meant to be some function that is not returning a value but an
> acoustic _side effect_. In an Algol representation something like the
> function
>
> bleep = (void) void: invoke_tone
>
> Or in Simula or Pascal the return-typeless function (= 'procedure')
>
> procedure bleep
>
> Or in C the function
>
> bleep() { invoke_tone; }
>
> In FORTRAN and BASIC (don't remember) that function was maybe called
> "subroutine"?
>
> Nomenclature changes wording but not its underlying character. Use the
> terms and models that fit best your goals. Meta-goals may be to clarify
> or to muddy the issue or its details.
>
> The term "subroutine" (for me) comprises two aspects; a hierarchical
> relation, and a [computation] process character.
>
Yes, it sort of implied that a subroutine will be called from and return
control to what is ultimately a main routine. Most programs work like
that, but not all.

>
> I'm unsure whether you wanted to express that functions with return
> type void are different from functions that return non-void types and
> should thus not be called functions? Other's may say that "subroutine"
> is badly chosen since there's not necessarily a hierarchical semantic
> when using "procedures" in context of Simula's classes with coroutines.
> Or are you saying that any "non-pure" function generally relies on
> side-effects and should be considered and named differently? - I'm fine
> with it. As long as it's clear what goals we follow, and whether the
> nomenclature is appropriate for that specific goal (and not conflicts
> with other goals).
>
In many languages, including C, there's a difference between functions
that return a value and functions that don't, in that

if (realloc(ptr, 0))

is allowed

whilst

if (free(ptr))

is not. And that's important if you are writing a compiler. In C, it
doesn't capture anything important for the user. You can return values
via the return type or via passed in pointers, and that's not a design
decision with any big implications.
Now in some languages, but not C, realloc() would be a "function" and
free() a "procedure".

What I was saying was that these words already exist, but they aren't
being used in a very useful way, so lets use "function" for subroutines
which calculate something and "procedure" for subroutines which do
something. The we've got all sorts of benefits which are very similar to
both "pure functions" and "functional programming". They're related
ideas but a slightly different take on it.

However because people are so focused on "function shall mean a C
subroutine" the regulars rejected the usage, and insisted that a C
subroutine which calculates something shall be termed a "Malcolm
function". So that's we call them here. A "Malcolm function" is a C
function which is also a mathematical function.

If you separate out the Malcolm functions from the other functions, you
find that the Malcolm functions can be written portably. Which is the
main advantage of doing it.

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

On 29.01.2024 00:00, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 27.01.2024 21:17, Malcolm McLean wrote:
> [...]
>>> printf() is the
>>> main C interface to that, and supports integers, floats and strings, to
>>> a first approximation.
>>
>> It's not an approximation; printf() is _restricted_ to these types (and
>> a few more variants of these few basic types, to be correct).
>
> printf also supports pointer values with "%p". And it support single
> characters, which are not strings.
>
> strings of cousre absolutely do not have to be ASCII. Using printf to
> print data with embedded null bytes is tricky

I haven't tried with a pure C compiler but with a C++ compiler
it works fine (see below). - Just don't make the mistake to try
to embed a NUL inside a string constant, like

printf ("%s\n", "My\0string");

which won't work as some may expect (you will only see "My").

> -- but of course printf is
> not the only interface. We can print arbitrary data with putchar,
> fwrite, etc.

I use the Unix I/O functions as well (i.e. 'write' etc.).

With printf or cout I can print binary, non-ASCII, UTF-8 encoded
characters...

std::cout << "Ölübelkeitäußerung" << std::endl;
printf("%s\n", "Ölübelkeitäußerung");

$ utf8out
Ölübelkeitäußerung
Ölübelkeitäußerung

cout << (char)0x02 << (char)0x01 << (char)0x00 << (char)0xff
<< (char)0xfe << (char)0x80 << (char)0x7f << (char)0x0a;

printf("%c%c%c%c%c%c%c%c",
(char)0x02, (char)0x01, (char)0x00, (char)0xff,
(char)0xfe, (char)0x80, (char)0x7f, (char)0x0a);

$ binout | od -t x1
0000000 02 01 00 ff fe 80 7f 0a 02 01 00 ff fe 80 7f 0a
0000020

>
> And in environments like POSIX that don't distinguish between text and
> binary output streams,

Also keep in mind that you can modify the output system attributes;
in these cases of a modified channel you may not see what you sent.

> it can be perfectly sensible (though not 100%
> portable) to send binary data to stdout.

Not observed (by me) in the environments I was using the past decades.

Janis

On 1/28/24 18:00, Keith Thompson wrote:
....
> And in environments like POSIX that don't distinguish between text and
> binary output streams, it can be perfectly sensible (though not 100%
> portable) to send binary data to stdout.

I'm sure you know about the following, but for Malcolm's benefit, I want
to expand on that comment. In other environments, the fact that stdout
is initially a text stream means that freopen() would have to be used to
change it to a binary stream - but it is otherwise no more of a problem
than in a POSIX environment.

On 29/01/2024 16:18, David Brown wrote:
> On 28/01/2024 20:49, Malcolm McLean wrote:
>> On 28/01/2024 18:24, David Brown wrote:
>>>
>> I'd expect that most general purpose programs written by Norwegians
>> use an English interface, even if it isn't really expected that the
>> program will find an audience beyond some users in Norway. Except of
>> course for programs which in some way are about Norway.
>
> Why?
>
Generally programmers are educated people and educated people use
English for serious purposes. Not always of course and Norway might be
an exception. But I'd expect that in a Norweigian university, for
example, it would be forbidden to document a program in Norwegian or to
use non-English words for identifiers. And probably the same in a large
Norwegina company. I might be wrong about that and I have never visited
Norway or worked for a Norweigian employer (and obviously I couldn't do
so unless the policy I expect was followed).
>
>> I've never used standard output for binary data. It might be necessary
>> for webservers that serve images. But it strikes me as a poor design
>> decision.
>
> It's simply something you haven't considered.  Don't assume that the
> kind of programming /you/ do, or that /you/ have experience with, is in
> any way representative of other kinds of programming needs or practices.
>
Well no, I'm not the only programmer in the world and I work in a niche
which isn't very typical of the industry as a whole. But I don't think my
use of standard output is all that untypical. It's unacceptable for
anything released to customers and is used mainly for debugging. I also
use it for
hobby programming. But I don't write web serve programs that need to put
binary images on standard output, I wasn't aware that this is sometimes
necessary and, as I say, it strikes me as a poor design decision.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 29/01/2024 19:32, Malcolm McLean wrote:
> On 27/01/2024 11:36, Janis Papanagnou wrote:
>> On 27.01.2024 12:02, Malcolm McLean wrote:
>>> On 27/01/2024 10:34, Janis Papanagnou wrote:
>>>> On 27.01.2024 04:05, Malcolm McLean wrote:

> In many languages, including C, there's a difference between functions
> that return a value and functions that don't, in that

In some languages, yes.

>
> if (realloc(ptr, 0))
>
> is allowed
>
> whilst
>
> if (free(ptr))

struct S { int a, b; };

struct S foo(void);

foo() returns a value, but "if (foo())" is not allowed.

C does not make much difference between functions that return a value,
and those that don't. The key distinction is whether the "return"
statement must have an expression or must not have an expression.

I don't disagree that it can be useful to distinguish between different
types of functions. I /do/ disagree with your attempts to classify
them, which I do not think are useful or well-defined categories.

And just because particular terms are used in some other context, does
not mean you get to define them yourself for use in other contexts, or
apply to them to languages that do not use those terms.

A "function" here is a "C function" in terms of the C standard. If you
want to talk about anything else, define what you mean at the time.

On 2024-01-29, David Brown <david.brown@hesbynett.no> wrote:
> On 29/01/2024 19:32, Malcolm McLean wrote:
>> On 27/01/2024 11:36, Janis Papanagnou wrote:
>>> On 27.01.2024 12:02, Malcolm McLean wrote:
>>>> On 27/01/2024 10:34, Janis Papanagnou wrote:
>>>>> On 27.01.2024 04:05, Malcolm McLean wrote:
>
>
>> In many languages, including C, there's a difference between functions
>> that return a value and functions that don't, in that
>
> In some languages, yes.
>
>>
>> if (realloc(ptr, 0))
>>
>> is allowed
>>
>> whilst
>>
>> if (free(ptr))
>
> struct S { int a, b; };
>
> struct S foo(void);
>
> foo() returns a value, but "if (foo())" is not allowed.
>
> C does not make much difference between functions that return a value,
> and those that don't. The key distinction is whether the "return"
> statement must have an expression or must not have an expression.

Don't forget that we can have:

struct S s = foo();

not to mention

struct S bar(void) { return foo(); }

as well as:

extern bar(struct S);

bar(foo());

none of which patterns is possible if foo returns void.

A void return is qualitatively different. A function which returns
a value can plausibly belong into the functional domain. A function
which returns void is necessarily an imperative procedure.

Even if it does nothing, a void foo() function it is a procedure in that
it cannot be planted into a functional expression like bar(foo()).

So we can identify an emergent category there.

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

On 29/01/2024 19:47, Malcolm McLean wrote:
> On 29/01/2024 16:18, David Brown wrote:
>> On 28/01/2024 20:49, Malcolm McLean wrote:
>>> On 28/01/2024 18:24, David Brown wrote:
>>>>
>>> I'd expect that most general purpose programs written by Norwegians
>>> use an English interface, even if it isn't really expected that the
>>> program will find an audience beyond some users in Norway. Except of
>>> course for programs which in some way are about Norway.
>>
>> Why?
>>
> Generally programmers are educated people and educated people use
> English for serious purposes.

I think you should probably stop there before you insult people.

> Not always of course and Norway might be
> an exception. But I'd expect that in a Norweigian university, for
> example, it would be forbidden to document a program in Norwegian or to
> use non-English words for identifiers. And probably the same in a large
> Norwegina company. I might be wrong about that and I have never visited
> Norway or worked for a Norweigian employer (and obviously I couldn't do
> so unless the policy I expect was followed).

You are wrong. And it is not something special about Norway.

You are coming across as the kind of ignorant and inconsiderate git who
thinks the way to talk to Jonny Foreigner is slowly and loudly.

Please stop before you embarrass yourself more.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

[...]

> I've never used standard output for binary data.
> [...] it strikes me as a poor design decision.

How so?

On 29/01/2024 20:35, Kaz Kylheku wrote:
> On 2024-01-29, David Brown <david.brown@hesbynett.no> wrote:
>> On 29/01/2024 19:32, Malcolm McLean wrote:
>>> On 27/01/2024 11:36, Janis Papanagnou wrote:
>>>> On 27.01.2024 12:02, Malcolm McLean wrote:
>>>>> On 27/01/2024 10:34, Janis Papanagnou wrote:
>>>>>> On 27.01.2024 04:05, Malcolm McLean wrote:
>>
>>
>>> In many languages, including C, there's a difference between functions
>>> that return a value and functions that don't, in that
>>
>> In some languages, yes.
>>
>>>
>>> if (realloc(ptr, 0))
>>>
>>> is allowed
>>>
>>> whilst
>>>
>>> if (free(ptr))
>>
>> struct S { int a, b; };
>>
>> struct S foo(void);
>>
>> foo() returns a value, but "if (foo())" is not allowed.
>>
>> C does not make much difference between functions that return a value,
>> and those that don't. The key distinction is whether the "return"
>> statement must have an expression or must not have an expression.
>
> Don't forget that we can have:
>
> struct S s = foo();
>
> not to mention
>
> struct S bar(void) { return foo(); }
>
> as well as:
>
> extern bar(struct S);
>
> bar(foo());
>
> none of which patterns is possible if foo returns void.

Sure. But Malcolm suggested that the "if" pattern was a special
distinguishing feature. (He has already made it clear that the only
types of interest, in his world, are integers, floats and strings.)

>
> A void return is qualitatively different. A function which returns
> a value can plausibly belong into the functional domain. A function
> which returns void is necessarily an imperative procedure.
>
> Even if it does nothing, a void foo() function it is a procedure in that
> it cannot be planted into a functional expression like bar(foo()).
>
> So we can identify an emergent category there.
>

Certainly there is a distinction between void and non-void functions -
but often it is not a particularly important one. What a function does,
what kind of side-effects it has, how its behaviour and values interact
with other parts of the code, how it interacts with other threads, are
far more interesting aspects for classification. (And part of the
interest is that these features are not normally specified in the code.)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 29.01.2024 00:00, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 27.01.2024 21:17, Malcolm McLean wrote:
>> [...]
>>>> printf() is the
>>>> main C interface to that, and supports integers, floats and strings, to
>>>> a first approximation.
>>>
>>> It's not an approximation; printf() is _restricted_ to these types (and
>>> a few more variants of these few basic types, to be correct).
>>
>> printf also supports pointer values with "%p". And it support single
>> characters, which are not strings.
>>
>> strings of cousre absolutely do not have to be ASCII. Using printf to
>> print data with embedded null bytes is tricky
>
> I haven't tried with a pure C compiler but with a C++ compiler
> it works fine (see below). - Just don't make the mistake to try
> to embed a NUL inside a string constant, like
>
> printf ("%s\n", "My\0string");
>
> which won't work as some may expect (you will only see "My").

Right, that's what's tricky about it. printf with "%s" treats the
corresponding argument as a pointer to a string, which means that it
ignores anything after the first null character. If you want to print
"My", followed by a null byte, followed by "string", you'll have to use
a different technique.

And the argument doesn't have to be a string constant for this to be
relevant. Printing arbitrary data with printf("%s", ...) is likely to
fail if the data contains null bytes. fwrite() is likely to be a better
choice. Both printf() and fwrite() work as if by repeated calls to
fputc().

[...]
>> it can be perfectly sensible (though not 100% portable) to send
>> binary data to stdout.
>
> Not observed (by me) in the environments I was using the past decades.

To list the contents of a .tgz file, you can do:

zcat foo.tgz | tar tf -

zcat and tar are implemented in C (I think; if not, they certainly could
be). In this command, zcat is writing binary data to stdout, and tar is
reading binary data from stdin. (GNU tar can also read directly from a
gzipped tar file, but that doesn't wouldn't illustrate the point.)

Of course all this can fail on systems with a strong distinction between
text and binary streams.

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

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/28/24 18:00, Keith Thompson wrote:
> ...
>> And in environments like POSIX that don't distinguish between text and
>> binary output streams, it can be perfectly sensible (though not 100%
>> portable) to send binary data to stdout.
>
> I'm sure you know about the following, but for Malcolm's benefit, I want
> to expand on that comment. In other environments, the fact that stdout
> is initially a text stream means that freopen() would have to be used to
> change it to a binary stream - but it is otherwise no more of a problem
> than in a POSIX environment.

I actually didn't know (or didn't remember) that freopen() with a null
pointer as the filename argument changes the mode of the stream. That
ability was added in C99.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 29/01/2024 16:18, David Brown wrote:
>> On 28/01/2024 20:49, Malcolm McLean wrote:
>>> On 28/01/2024 18:24, David Brown wrote:
>>> I'd expect that most general purpose programs written by Norwegians
>>> use an English interface, even if it isn't really expected that the
>>> program will find an audience beyond some users in Norway. Except
>>> of course for programs which in some way are about Norway.
>> Why?
>>
> Generally programmers are educated people and educated people use
> English for serious purposes. Not always of course and Norway might be
> an exception. But I'd expect that in a Norweigian university, for
> example, it would be forbidden to document a program in Norwegian or
> to use non-English words for identifiers. And probably the same in a
> large Norwegina company. I might be wrong about that and I have never
> visited Norway or worked for a Norweigian employer (and obviously I
> couldn't do so unless the policy I expect was followed).

You assert that "educated people use English for serious purposes".
I don't have the experience to refute that claim, but I suspect
it's arrogant nonsense. I could be wrong, of course.

Even given that assumption, you ignore the possibility that programs
might be intended to be used by non-programmers. You ignore my own
examples of software I've worked on that can be configured to show all
messages in any of several languages, including Norwegian, presumably
because there's a demand for it. And you ignore the statements of
someone who lives in Norway and knows what he's talking about.

Consider not making definitive statements about things you don't know
about.

[...]

--
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 29/01/2024 20:10, Tim Rentsch wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> [...]
>
>> I've never used standard output for binary data.
>> [...] it strikes me as a poor design decision.
>
> How so?
>
Because the output can't be inspected by humans, and because it might
have unusual effects if passed though systems designed to handle
human-readable text. For instance in some systems designed to receive
ASCII text, there is no distinction between the nul byte and "waiting
for next data byte". Obviously this will cause difficuties if the data
is binary.
Also many binary formats can't easily be extended, so you can pass one
image and that's all. Whilst it is possible to devise a text format
which is similar, in practice text formats usually have enough
redundancy to be easily extended.

So it's harder to correct errors, more prone to errors, and harder to
extend.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 29/01/2024 20:10, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> [...]
>>
>>> I've never used standard output for binary data.
>>> [...] it strikes me as a poor design decision.
>>
>> How so?
> >
>Because the output can't be inspected by humans

Sure it can. Pipe it to a the appropriate tool.

$ cat /usr/bin/xrn | xxd |head
0000000: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............
0000010: 0200 3e00 0100 0000 ac47 4000 0000 0000 ..>......G@.....
0000020: 4000 0000 0000 0000 08a0 0500 0000 0000 @...............
0000030: 0000 0000 4000 3800 0900 4000 2200 1f00 ....@.8...@."...
0000040: 0600 0000 0500 0000 4000 0000 0000 0000 ........@.......
0000050: 4000 4000 0000 0000 4000 4000 0000 0000 @.@.....@.@.....
0000060: f801 0000 0000 0000 f801 0000 0000 0000 ................
0000070: 0800 0000 0000 0000 0300 0000 0400 0000 ................
0000080: 3802 0000 0000 0000 3802 4000 0000 0000 8.......8.@.....

On 29/01/2024 20:10, David Brown wrote:
> On 29/01/2024 20:35, Kaz Kylheku wrote:
>> On 2024-01-29, David Brown <david.brown@hesbynett.no> wrote:
>>> On 29/01/2024 19:32, Malcolm McLean wrote:
>>>> On 27/01/2024 11:36, Janis Papanagnou wrote:
>>>>> On 27.01.2024 12:02, Malcolm McLean wrote:
>>>>>> On 27/01/2024 10:34, Janis Papanagnou wrote:
>>>>>>> On 27.01.2024 04:05, Malcolm McLean wrote:
>>>
>>>
>>>> In many languages, including C, there's a difference between functions
>>>> that return a value and functions that don't, in that
>>>
>>> In some languages, yes.
>>>
>>>>
>>>> if (realloc(ptr, 0))
>>>>
>>>> is allowed
>>>>
>>>> whilst
>>>>
>>>> if (free(ptr))
>>>
>>> struct S { int a, b; };
>>>
>>> struct S foo(void);
>>>
>>> foo() returns a value, but "if (foo())" is not allowed.
>>>
>>> C does not make much difference between functions that return a value,
>>> and those that don't.  The key distinction is whether the "return"
>>> statement must have an expression or must not have an expression.
>>
>> Don't forget that we can have:
>>
>>    struct S s = foo();
>>
>> not to mention
>>
>>    struct S bar(void) { return foo(); }
>>
>> as well as:
>>
>>    extern bar(struct S);
>>
>>    bar(foo());
>>
>> none of which patterns is possible if foo returns void.
>
> Sure.  But Malcolm suggested that the "if" pattern was a special
> distinguishing feature.  (He has already made it clear that the only
> types of interest, in his world, are integers, floats and strings.)
>
No, Malcolm gave if() as an example of a distinction in a language grammar
between functions that return a value and functions that don't. Sometimes
functions return a value and if() still isn't allowed. Fair enough
point.But it doesn't really detract from the point that Malcolm is makin

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