On 27/01/2024 20:17, Malcolm McLean wrote:
> You can of course encode any data format as any other as long as you can
> write enough. But standard output can't take images or audio, for example.

What?

stdout is perfectly happy with anything, eg:

$ cat a.out | xxd | head -1
00000000: cffa edfe 0c00 0001 0000 0000 0200 0000 ................

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

> On Tue, 23 Jan 2024 12:09:09 -0800, Keith Thompson wrote:
>
>> C's predecessor language B ...
>
> Let me see if I understand the genealogy:
>
> B was an adaptation of Martin Richards’ BCPL. BCPL was a low-level,
> typeless language designed for system programming. It originated before
> byte-addressable machines became popular.

> In fact, Richards looked at
> adapting BCPL to the PDP-11, and came away unimpressed with the latter’s
> architecture.

I didn't know that. Do you have a reference I can read?

> So B was BCPL adapted by the Bell Labs crew to work on a byte-addressable
> machine.

Not really. B also worked on words. There were no language changes
aimed at byte addressing. Both B and early BCPL accessed bytes with
library functions. I say early BCPL because, while B evolved in to C,
BCPL also evolved and later acquired a byte access operator, "%", along
with the word access one: "!".

> But it still didn’t have types. And types turned out to be rather
> important to the implementation of a decent OS and accompanying
> software.

Yes. Early C had types, but there were hardly checked. Their main
purposes were to allow structures to be defined and to allow convenient
access to operations that in B and BCPL needed different operators.
Apart from the obvious byte, short, int and long accesses expressed
using * and [..], C could also express integer and floating point
addition with the same operator symbols. BCPL needed separate symbols
for that and could not do mix-mode arithmetic with any ease at all.

> So the Bell Labs came up with the successor language C, which did have
> types.

--
Ben.

I just use the compose key for all nonascii because i find it more
convenient to have everything in one place.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Despite the fact that you're killing everybody, here's a million dollars.

On 27/01/2024 20:49, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote:
>
>> On 27/01/2024 02:10, James Kuyper wrote:
>>
>>> On 1/26/24 12:31, Janis Papanagnou wrote:
>>
>>>> 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.
>>>
>> Try telling that to Haskell programmers :-)
>
> The dirty little secret of pure-functional programming is that I/O cannot
> be treated in a purely functional fashion.
>
So the model is input - calculation - output.

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

On Sat, 27 Jan 2024 22:12:56 +0000, Ben Bacarisse wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> In fact, Richards looked at adapting BCPL to the PDP-11, and came away
>> unimpressed with the latter’s architecture.

>I didn't know that. Do you have a reference I can read?

I was trying to look for one, but couldn’t find it. I recall it had
something to do with a report by Richards into the portability of BCPL.

>> So B was BCPL adapted by the Bell Labs crew to work on a
>> byte-addressable machine.
>
> Not really. B also worked on words.

Yeah. According to this
<https://user-web.icecube.wisc.edu/~dglo/c_class/history.html>, it was
used on the PDP-7, and turned out to be unsuitable for the byte-
addressable PDP-11.

Elsewhere I read that B was a very close port of BCPL.

> I say early BCPL because, while B evolved in to C,
> BCPL also evolved and later acquired a byte access operator, "%", along
> with the word access one: "!".

There a was a language used at DEC, called BLISS, which was typeless like
BCPL. But it accessed things as generalized bitfields (I think assuming
the compiler would suitably optimize constant values for offsets and bit
widths). So it worked fine on byte-addressable machines. It was used for
some system software on VMS.

On Sat, 27 Jan 2024 21:40:31 +0000, Richard Harnden wrote:

> $ cat a.out | xxd | head -1 00000000: cffa edfe 0c00 0001 0000 0000 0200
> 0000 ................

UUOC!

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 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'm reasonably sure you saw my previous followup, in which I pointed out
that (a) ISO C does not support reordering arguments to printf, and (b)
in any language, you can reorder arguments by building a string that you
then send to output.

C++ also lets you define output operators for any type, something that's
much more difficult with printf-style output.

[...]

--
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 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>
>> What I am saying is that standard output can take integers, floats and
>> strings.
>
> You forgot booleans. Also enumerations can be useful.
>
Yes, and we could say fixed point, complex, etc.
It's not inherently a bad idea to extend our little stdout interface to
include booleans. But in fact there are too many output formats you
might need.
Fixed point - in C or C++ there's no standard for that, so now you are
going the OO route. As you would with enumerations as the symbol doesn't
exist at runtime.
It's not that there is no case to be made for the OO approach. What I am
saying is that in practice the locked down restricted interface will
work better.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Sun, 28 Jan 2024 00:22:15 +0000, Malcolm McLean wrote:

> On 27/01/2024 20: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.
>>
> So the model is input - calculation - output.

So “functional” is really “procedural-functional-procedural”.

And what happens with interactive code? You need a loop around that
sequence--another procedural construct. And maybe a conditional exit--yet
another procedural construct.

On Sun, 28 Jan 2024 00:35:30 +0000, Malcolm McLean wrote:

> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>
>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>
>>> What I am saying is that standard output can take integers, floats and
>>> strings.
>>
>> You forgot booleans. Also enumerations can be useful.
>>
> Yes, and we could say fixed point, complex, etc.

Booleans and enumerations (enumerations can be considered a generalization
of booleans) are ones that could usefully be displayed in symbolic form.
Python example:

for i in (1, 2, 3) :
print("%d = %d? %s" % (i, 2, i == 2))
#end for

produces output:

1 = 2? False
2 = 2? True
3 = 2? False

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>
>>> What I am saying is that standard output can take integers, floats and
>>> strings.
>> You forgot booleans. Also enumerations can be useful.
>>
> Yes, and we could say fixed point, complex, etc.
> It's not inherently a bad idea to extend our little stdout interface
> to include booleans. But in fact there are too many output formats you
> might need.
> Fixed point - in C or C++ there's no standard for that, so now you are
> going the OO route. As you would with enumerations as the symbol
> doesn't exist at runtime.
> It's not that there is no case to be made for the OO approach. What I
> am saying is that in practice the locked down restricted interface
> will work better.

I think you mean it will work Malcolm-better.

Apparently inflexibility and vulnerability to type errors are
Malcolm-better than the alternative.

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

David Brown <david.brown@hesbynett.no> writes:
> For my own use, I've sometimes used classes letting you do :
>
> debug_log << "X = " << x << " = 0x" << hex(x, 8) << "\n";
>
> "hex(x, 8)" returns a value of a class holding "x" and the number of
> digits 8, and then there is an overload for the << operator on this
> class. No extra state needs to be stored in the logging class, I can
> make as many of these formatters as I like, and the intermediary
> classes all disappear in the optimisation.

Or hex() could just return a std::string.

[...]

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

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

Which is why horseless carriages never caught on.

Perhaps you could have picked a better analogy. In any case, there are
plenty of non-POSIX C environments -- and comp.unix.programmer is a
great place to discuss POSIX. (Which is not to suggest that we can't
mention POSIX here.)

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

David Brown <david.brown@hesbynett.no> writes:
[...]
> Seriously, how hard would it be for you to accept the usage of
> "function" to mean "C function" in this group? How difficult would it
> be for you to try to speak the same language as the rest of us? Do
> you really expect everyone else to adapt to suit your personal choice
> of definitions? How often do you need to go round the same circles
> again and again, instead of trying to communicate with people in a
> sane manner?

You don't really think difficulty is the issue, do you?

--
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 Sat, 27 Jan 2024 17:34:00 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> C and POSIX go together like a horse and carriage; one without the
>> other is a lot less useful.
>
> Which is why horseless carriages never caught on.

No, they never did. Until something was invented ... what was it ...
something to do with “horsepower” ...

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 27 Jan 2024 17:34:00 -0800, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> C and POSIX go together like a horse and carriage; one without the
>>> other is a lot less useful.
>>
>> Which is why horseless carriages never caught on.
>
> No, they never did. Until something was invented ... what was it ...
> something to do with “horsepower” ...

*whoosh*

--
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 28/01/2024 01:26, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>>
>>>> What I am saying is that standard output can take integers, floats and
>>>> strings.
>>> You forgot booleans. Also enumerations can be useful.
>>>
>> Yes, and we could say fixed point, complex, etc.
>> It's not inherently a bad idea to extend our little stdout interface
>> to include booleans. But in fact there are too many output formats you
>> might need.
>> Fixed point - in C or C++ there's no standard for that, so now you are
>> going the OO route. As you would with enumerations as the symbol
>> doesn't exist at runtime.
>> It's not that there is no case to be made for the OO approach. What I
>> am saying is that in practice the locked down restricted interface
>> will work better.
>
> I think you mean it will work Malcolm-better.
>
> Apparently inflexibility and vulnerability to type errors are
> Malcolm-better than the alternative.
>
Exactly.
Inflexibility can be better. Because in reality most program work with a
restricted set of data types which it makes sense to pass to a text
stream, and so you only need three atomic types.

Tpye errors are of course a nuisance with printf(). But that's because
of the quirks of C, not because it takes a restricted set of types, and
you can write a different restricted interface without this problem.

The fact is that printf(), which works basically as I recommend, is
widely used as the interface to standard output, and often OO
alternatives are available and not used for various reasons.

So the world is in fact "Malcolm better".

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

On 28/01/2024 01:18, Lawrence D'Oliveiro wrote:
> On Sun, 28 Jan 2024 00:22:15 +0000, Malcolm McLean wrote:
>
>> On 27/01/2024 20: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.
>>>
>> So the model is input - calculation - output.
>
> So “functional” is really “procedural-functional-procedural”.
>
> And what happens with interactive code? You need a loop around that
> sequence--another procedural construct. And maybe a conditional exit--yet
> another procedural construct.
>
Exactly. Some programs essentially calculate something. The data is
input, transformed, and you get output. But others don't. They provide a
virual world which the user can manipulate. The calculations and data
transformations are often pretty trivial, and all the programming effort
is in supporting the user interface. And so you need a different
conceptual model.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 1/27/2024 5:34 PM, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> 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.
>
> Which is why horseless carriages never caught on.

:^D

>
> Perhaps you could have picked a better analogy. In any case, there are
> plenty of non-POSIX C environments -- and comp.unix.programmer is a
> great place to discuss POSIX. (Which is not to suggest that we can't
> mention POSIX here.)
>

On 1/27/24 10:44, David Brown wrote:
> On 27/01/2024 02:10, James Kuyper wrote:
>> On 1/26/24 12:31, Janis Papanagnou wrote:
>
>>> 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.
>>
>
> Try telling that to Haskell programmers :-)

I was talking very specifically in reference to C's definition of
"side-effect". I'm not particularly familiar with Haskell - does it have
a different definition of "side effect", or does it somehow get
something useful done without qualifying under C's definition? If so, how?

On 27/01/2024 21:49, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote:
>
>> On 27/01/2024 02:10, James Kuyper wrote:
>>
>>> On 1/26/24 12:31, Janis Papanagnou wrote:
>>
>>>> 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.
>>>
>> Try telling that to Haskell programmers :-)
>
> 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.

I must admit that I have never done any IO in a functional programming
language. All my usage has been with "pure" functions, and it is also
quite out of date.

On 28/01/2024 07:31, James Kuyper wrote:
> On 1/27/24 10:44, David Brown wrote:
>> On 27/01/2024 02:10, James Kuyper wrote:
>>> On 1/26/24 12:31, Janis Papanagnou wrote:
>>
>>>> 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.
>>>
>>
>> Try telling that to Haskell programmers :-)
>
> I was talking very specifically in reference to C's definition of
> "side-effect". I'm not particularly familiar with Haskell - does it have
> a different definition of "side effect", or does it somehow get
> something useful done without qualifying under C's definition? If so, how?
>

Pure functional programming does not have side-effects, at least not in
the way we are familiar with in C. There are various techniques used by
different functional programming languages to do things like IO, but
that's all way off-topic (and beyond my knowledge and understanding).

On 28/01/2024 02:31, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> For my own use, I've sometimes used classes letting you do :
>>
>> debug_log << "X = " << x << " = 0x" << hex(x, 8) << "\n";
>>
>> "hex(x, 8)" returns a value of a class holding "x" and the number of
>> digits 8, and then there is an overload for the << operator on this
>> class. No extra state needs to be stored in the logging class, I can
>> make as many of these formatters as I like, and the intermediary
>> classes all disappear in the optimisation.
>
> Or hex() could just return a std::string.
>

Yes. That can make the coding a lot simpler, and very flexible. But it
comes at a cost - in my type of work, I don't want any dynamic memory
unless it is absolutely unavoidable, and I want results to be as
efficient as practically possible. On the other hand, I don't need the
generality that you would have in a larger and more general purpose
framework. That all means tighter connections between the "log" class
and the functions handling these outputs.

(One possibility that is not bad is to have support for handling
fixed-length strings, rather than std::string. Real implementations of
this kind of thing are more complicated, with templates and all, and
well outside of c.l.c.)

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.

It's fine to use POSIX functions when your target is POSIX. But the
target for C programmers is not always POSIX.

On 28/01/2024 02:59, Malcolm McLean wrote:
> On 28/01/2024 01:26, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On 27/01/2024 21:06, Lawrence D'Oliveiro wrote:
>>>> On Sat, 27 Jan 2024 11:13:16 +0000, Malcolm McLean wrote:
>>>>
>>>>> What I am saying is that standard output can take integers, floats and
>>>>> strings.
>>>> You forgot booleans. Also enumerations can be useful.
>>>>
>>> Yes, and we could say fixed point, complex, etc.
>>> It's not inherently a bad idea to extend our little stdout interface
>>> to include booleans. But in fact there are too many output formats you
>>> might need.
>>> Fixed point - in C or C++ there's no standard for that, so now you are
>>> going the OO route. As you would with enumerations as the symbol
>>> doesn't exist at runtime.
>>> It's not that there is no case to be made for the OO approach. What I
>>> am saying is that in practice the locked down restricted interface
>>> will work better.
>>
>> I think you mean it will work Malcolm-better.
>>
>> Apparently inflexibility and vulnerability to type errors are
>> Malcolm-better than the alternative.
>>
> Exactly.
> Inflexibility can be better. Because in reality most program work with a
> restricted set of data types which it makes sense to pass to a text
> stream, and so you only need three atomic types.
>
> Tpye errors are of course a nuisance with printf(). But that's because
> of the quirks of C, not because it takes a restricted set of types, and
> you can write a different restricted interface without this problem.
>
> The fact is that printf(), which works basically as I recommend, is
> widely used as the interface to standard output, and often OO
> alternatives are available and not used for various reasons.
>
> So the world is in fact "Malcolm better".
>

You mean the Malcolm-world is Malcolm-better with these restrictions,
because in the Malcolm-world the only programming tasks that are done
are Malcolm-tasks, and the programmers are all Malcolm-programmers.

At least that's all cleared up nicely, and the rest of the world can go
back to using more than three types, and generating outputs that are not
just ASCII text.