On 10/04/2024 19:19, Kaz Kylheku wrote:
> On 2024-04-10, David Brown <david.brown@hesbynett.no> wrote:
>> Basically, anything you could do with a nested function in gcc C you can
>> do in C++:
>
> Except pass that lambda to another module that expects a simple function
> pointer.

If the lambda has no captures, then you can do that. (I don't know if
this is supported by the C++ standards, or merely works in practice.)

>
> That's not just C libraries. There is a foreign function ecosystem based
> on the conventions of C. If you have a function pointer, you can pass it
> into any high level language that supports C interpo, and it can call
> that thing.
>

On Wed, 10 Apr 2024 14:23:38 GMT, Scott Lurndal wrote:

> The Burroughs Algol systems used something called lex levels to handle
> nested functions.

There are two techniques used in languages that allow nested scopes with
lexical binding: they are called “static link” and “display array”.

On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:

> Just for your entertainment, with C++ lambdas this is now legal code:
>
> void foo(void) {
> [](){}();
> }

C programmer still has habit of writing “(void)” when C++ allows “()”
instead.

Does the latest C spec now also take “()” to mean “no args” (synonymous
with “(void)”) instead of “unspecified args”?

On 2024-04-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>
>> Just for your entertainment, with C++ lambdas this is now legal code:
>>
>> void foo(void) {
>> [](){}();
>> }
>
> C programmer still has habit of writing “(void)” when C++ allows “()”
> instead.

That is backwards. (void) is the dud that C++ "allows"; () is the
"native" empty parameter list in C++, and has been from the early
beginning.

C++ (originally C With Classes) introduced () as a prototyped, declared
parameter list. At that time there was no (void) in C, and therefore not
in C++ either.

In C, the () list, in a declaration, didn't say anything about the
number of parameters.

ANSI C came along and invented (void) in order not to change the meaning
of () for compatibility.

Then C++ adopted (void) for ANSI C compatibility.

I.e. (void) is concession that that C++ "allows", and did not always;
() is the "native" empty parameter list it always had.

It's monumentally stupid when you see (void) on feature that only exists
in C++ and therefore C compatibility is not involved:

myclass::myclass(void)
{
// default constructor
}

> Does the latest C spec now also take “()” to mean “no args” (synonymous
> with “(void)”) instead of “unspecified args”?

The N3320 working draft says:

"The special case of an unnamed parameter of type void as the only item
in the list specifies that the function has no parameters."
(6.7.7.4 Function declarators)

"For a function declarator without a parameter type list: the effect is
as if it were declared with a parameter type list consisting of the
keyword void. A function declarator provides a prototype for the
function." (ibid.)

The last sentence assures us that function declartions are now protypes;
there are no function declarators that do not prototype the parameters.

(Apologies to Kenny for the "ibid.")

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

On Wed, 10 Apr 2024 11:18:12 +0200, David Brown wrote:

> Basically, anything you could do with a nested function in gcc C you can
> do in C++:

Has anybody suggested adding coroutines to C++ yet?

E.g. Python equivalent to the permute function that uses a recursive
generator:

def permute(seq) :
if len(seq) == 0 :
yield ()
else :
for i in range(len(seq)) :
for rest in permute(seq[:i] + seq[i + 1:]) :
yield (seq[i],) + rest
#end for
#end for
#end if
#end permute

Example use:

for x in permute(("a", "b", "c")) :
print(x)
#end for

Output:

('a', 'b', 'c')
('a', 'c', 'b')
('b', 'a', 'c')
('b', 'c', 'a')
('c', 'a', 'b')
('c', 'b', 'a')

And then there’s the fun you can have with async/await ...

On 2024-04-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> Has anybody suggested adding coroutines to C++ yet?

Your training data isn't very recent, evidently.

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

In article <20240410174139.914@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
....
>(Apologies to Kenny for the "ibid.")

Heh heh. Got that one. Had to think for a minute or so, though.

Anyway, just for the record, I was specifically talking about things like
"ad hominem" - i.e., all those terms for supposedly bad arguments. Like
"ad populem" (Or however you spell it...) and so on.

Basically, I am saying that when someone uses the term "ad hominem", they
are conceding that they have lost the argument.

--
Trump has normalized hate.

The media has normalized Trump.

On 11/04/2024 02:18, Lawrence D'Oliveiro wrote:
> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>
>> Just for your entertainment, with C++ lambdas this is now legal code:
>>
>> void foo(void) {
>> [](){}();
>> }
>
> C programmer still has habit of writing “(void)” when C++ allows “()”
> instead.

I do that sometimes, yes. I could argue that I think it is better to be
explicit than implicit, but it's just my fingers on automatic. The
kinds of programs I work on can rarely be pure C++ - there's always lots
of C code too, and it's often useful to write code in a way that is
suitable for both C and C++.

In this particular case, of course, there's not much advantage to having
a C-style function declaration!

>
> Does the latest C spec now also take “()” to mean “no args” (synonymous
> with “(void)”) instead of “unspecified args”?

It does, yes, in C23. If you want to declare a function with no
information about the number or type of parameters, you can now write
"void foo(...);". (Prior to C23 you needed at least one normal typed
parameter before the ellipsis.)

On 11/04/2024 02:54, Lawrence D'Oliveiro wrote:
> On Wed, 10 Apr 2024 11:18:12 +0200, David Brown wrote:
>
>> Basically, anything you could do with a nested function in gcc C you can
>> do in C++:
>
> Has anybody suggested adding coroutines to C++ yet?
>

It's in C++20.

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

I have not looked at them myself, or checked the status of support in
C++ compilers and standard libraries.

On Thu, 11 Apr 2024 10:23:03 +0200, David Brown wrote:

> On 11/04/2024 02:54, Lawrence D'Oliveiro wrote:
>
>> Has anybody suggested adding coroutines to C++ yet?
>>
> It's in C++20.
>
> <https://en.cppreference.com/w/cpp/language/coroutines>

Can’t have variadic arguments, and can’t be constructors.

In Python, “__init__()” cannot be async, but “__new__()” can. So you can
do async class instantiation, after all.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 10 Apr 2024 14:23:38 GMT, Scott Lurndal wrote:
>
>> The Burroughs Algol systems used something called lex levels to handle
>> nested functions.
>
>There are two techniques used in languages that allow nested scopes with
>lexical binding: they are called “static link” and “display array”.

What does that have to do with the Burroughs hardware support for
lexical levels?

David Brown <david.brown@hesbynett.no> writes:
>On 11/04/2024 02:18, Lawrence D'Oliveiro wrote:
>> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>>
>>> Just for your entertainment, with C++ lambdas this is now legal code:
>>>
>>> void foo(void) {
>>> [](){}();
>>> }
>>
>> C programmer still has habit of writing “(void)” when C++ allows “()”
>> instead.
>
>I do that sometimes, yes. I could argue that I think it is better to be
>explicit than implicit, but it's just my fingers on automatic.

I would use the same argument. Make it explicit.

On 2024-04-11, Scott Lurndal <scott@slp53.sl.home> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>On 11/04/2024 02:18, Lawrence D'Oliveiro wrote:
>>> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>>>
>>>> Just for your entertainment, with C++ lambdas this is now legal code:
>>>>
>>>> void foo(void) {
>>>> [](){}();
>>>> }
>>>
>>> C programmer still has habit of writing “(void)” when C++ allows “()”
>>> instead.
>>
>>I do that sometimes, yes. I could argue that I think it is better to be
>>explicit than implicit, but it's just my fingers on automatic.
>
> I would use the same argument. Make it explicit.

(void) is a dongle intoduced in ANSI C so that () could continue
to mean "unknown number of parameters". It didn't exist in C++
until ANSI C invented it.

() is a perfectly explicit empty list. (void) does not look empty;
it looks like it's declaring one parameter of type void.

An actual implicit empty parameter list might look like this:

function foo
{
}

Once you have empty parentheses, that is explicit.

Countless programming languages have only (); no such thing as (void) or
similar ugly hack, due to not having a quirky history that would have
caused such a thing to be required.

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

On 2024-04-11, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20240410174139.914@kylheku.com>,
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> ...
>>(Apologies to Kenny for the "ibid.")
>
> Heh heh. Got that one. Had to think for a minute or so, though.
>
> Anyway, just for the record, I was specifically talking about things like
> "ad hominem" - i.e., all those terms for supposedly bad arguments. Like
> "ad populem" (Or however you spell it...) and so on.
>
> Basically, I am saying that when someone uses the term "ad hominem", they
> are conceding that they have lost the argument.

Wait, isn't that "ad hit"? (adolf hitlerum)

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

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>On 2024-04-11, Scott Lurndal <scott@slp53.sl.home> wrote:
>> David Brown <david.brown@hesbynett.no> writes:

>>>I do that sometimes, yes. I could argue that I think it is better to be
>>>explicit than implicit, but it's just my fingers on automatic.
>>
>> I would use the same argument. Make it explicit.
>
>(void) is a dongle intoduced in ANSI C so that () could continue
>to mean "unknown number of parameters". It didn't exist in C++
>until ANSI C invented it.
>
>() is a perfectly explicit empty list. (void) does not look empty;
>it looks like it's declaring one parameter of type void.
>
>An actual implicit empty parameter list might look like this:
>
> function foo
> {
> }
>
>Once you have empty parentheses, that is explicit.
>
>Countless programming languages have only (); no such thing as (void) or
>similar ugly hack, due to not having a quirky history that would have
>caused such a thing to be required.

Beauty is in the eye of the beholder. As someone who cut his
teeth on Unix V6, an empty parameter list is less self-documenting
than an explicit (void).

We're talking about C and C++ here, not 'countless programming languages".

On 11/04/2024 17:04, Kaz Kylheku wrote:
> On 2024-04-11, Scott Lurndal <scott@slp53.sl.home> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 11/04/2024 02:18, Lawrence D'Oliveiro wrote:
>>>> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>>>>
>>>>> Just for your entertainment, with C++ lambdas this is now legal code:
>>>>>
>>>>> void foo(void) {
>>>>> [](){}();
>>>>> }
>>>>
>>>> C programmer still has habit of writing “(void)” when C++ allows “()”
>>>> instead.
>>>
>>> I do that sometimes, yes. I could argue that I think it is better to be
>>> explicit than implicit, but it's just my fingers on automatic.
>>
>> I would use the same argument. Make it explicit.
>
> (void) is a dongle intoduced in ANSI C so that () could continue
> to mean "unknown number of parameters". It didn't exist in C++
> until ANSI C invented it.

I like history as much as the next person - probably more so, and thus I
do appreciate you explaining where this comes from. But I don't base my
programming choices or style on history. From the point of view of
current programming, it's irrelevant when "(void)" was introduced to C
and C++, it's only relevant what it means /now/ to the compiler, and
what it means to someone reading the code.

I write "(void)" in C code, or in C++ code that might be seen by a C
compiler (such as in a header file that could be used with C or C++), or
if it might be read by someone who is more familiar with C than C++. If
the code is "pure C++", such as this example, I normally don't bother
with "(void)". But I don't object to it either.

>
> () is a perfectly explicit empty list. (void) does not look empty;
> it looks like it's declaring one parameter of type void.

"void" has always been a bit weird as a "type" or as a placeholder for
an empty type.

>
> An actual implicit empty parameter list might look like this:
>
> function foo
> {
> }
>
> Once you have empty parentheses, that is explicit.
>

"(void)" stands out more.

> Countless programming languages have only (); no such thing as (void) or
> similar ugly hack, due to not having a quirky history that would have
> caused such a thing to be required.
>

It has never struck me as "ugly", but it is arguably quirky.

In article <20240411081303.407@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-04-11, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <20240410174139.914@kylheku.com>,
>> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>> ...
>>>(Apologies to Kenny for the "ibid.")
>>
>> Heh heh. Got that one. Had to think for a minute or so, though.
>>
>> Anyway, just for the record, I was specifically talking about things like
>> "ad hominem" - i.e., all those terms for supposedly bad arguments. Like
>> "ad populem" (Or however you spell it...) and so on.
>>
>> Basically, I am saying that when someone uses the term "ad hominem", they
>> are conceding that they have lost the argument.
>
>Wait, isn't that "ad hit"? (adolf hitlerum)

I don't know what that means.

(T. Brennan - Yes, I've started watching "Bones" again...)

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Noam

David Brown <david.brown@hesbynett.no> writes:
> On 11/04/2024 02:18, Lawrence D'Oliveiro wrote:
>> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>>
>>> Just for your entertainment, with C++ lambdas this is now legal code:
>>>
>>> void foo(void) {
>>> [](){}();
>>> }
>> C programmer still has habit of writing “(void)” when C++ allows
>> “()”
>> instead.
>
> I do that sometimes, yes. I could argue that I think it is better to
> be explicit than implicit, but it's just my fingers on automatic. The
> kinds of programs I work on can rarely be pure C++ - there's always
> lots of C code too, and it's often useful to write code in a way that
> is suitable for both C and C++.
>
> In this particular case, of course, there's not much advantage to
> having a C-style function declaration!
>
>> Does the latest C spec now also take “()” to mean “no args”
>> (synonymous
>> with “(void)”) instead of “unspecified args”?
>
> It does, yes, in C23. If you want to declare a function with no
> information about the number or type of parameters, you can now write
> "void foo(...);". (Prior to C23 you needed at least one normal typed
> parameter before the ellipsis.)

That's not quite the same. (...) declares a variadic function, whose
arguments (if any) can be accessed using the macros in <stdarg.h>.
Functions with an old-style () declaration can access their arguments by
names given in the definition Variadic functions could have a different
calling convention.

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

scott@slp53.sl.home (Scott Lurndal) writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Wed, 10 Apr 2024 14:23:38 GMT, Scott Lurndal wrote:
>>
>>> The Burroughs Algol systems used something called lex levels to handle
>>> nested functions.
>>
>>There are two techniques used in languages that allow nested scopes with
>>lexical binding: they are called "static link" and "display array".
>
> What does that have to do with the Burroughs hardware support for
> lexical levels?

I don't know all Burroughs hardware, but the famous B5000 accessed lex
levels using a set of 32 "D" registers. This is exactly what a "display
array" is. I suspect the register set's name (D) is a nod to the
conventional name for the technique.

PS. Can you get your newsreader to at least leave UTF-8 posting headers
un-changed? Passing the bytes through but removing the "charset"
declaration leads to mojibake.

--
Ben.

On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:

> As someone who cut his teeth on
> Unix V6, an empty parameter list is less self-documenting than an
> explicit (void).

Should that apply when calling the function as well?

res = func(void);

instead of

res = func();

?

On 2024-04-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:
>
>> As someone who cut his teeth on
>> Unix V6, an empty parameter list is less self-documenting than an
>> explicit (void).
>
> Should that apply when calling the function as well?

Scott is getting burned by the current resident imbecile,
how embarrassing.

> res = func(void);
>
> instead of
>
> res = func();

Well, according to the eccentric coding conventions followed by your
team of one, indeed, yes; shouldn't it be:

res = func(/* void */);

No, wait:

res = func(
/* void = nothing */
); /* func( */

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

On 12.04.2024 04:31, Lawrence D'Oliveiro wrote:
> On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:
>
>> As someone who cut his teeth on
>> Unix V6, an empty parameter list is less self-documenting than an
>> explicit (void).
>
> Should that apply when calling the function as well?
>
> res = func(void);
>
> instead of
>
> res = func();
>
> ?

Ideally it would be (without syntactic ballast) just

res = func;

(as many programming languages have it designed), in
function definition and function call; no parameters,
no unnecessary parenthesis.

(Even Algol 68, where I've seen 'void' mentioned for
the first time, does not use 'void' for an empty
function argument list definition or function call.)

But we use C here, so we have to take what's given.

Janis

On 12/04/2024 07:32, Janis Papanagnou wrote:
> On 12.04.2024 04:31, Lawrence D'Oliveiro wrote:
>> On Thu, 11 Apr 2024 15:15:35 GMT, Scott Lurndal wrote:
>>
>>> As someone who cut his teeth on
>>> Unix V6, an empty parameter list is less self-documenting than an
>>> explicit (void).
>>
>> Should that apply when calling the function as well?
>>
>> res = func(void);
>>
>> instead of
>>
>> res = func();
>>
>> ?
>
> Ideally it would be (without syntactic ballast) just
>
> res = func;
>
> (as many programming languages have it designed), in
> function definition and function call; no parameters,
> no unnecessary parenthesis.
>
> (Even Algol 68, where I've seen 'void' mentioned for
> the first time, does not use 'void' for an empty
> function argument list definition or function call.)
>
> But we use C here, so we have to take what's given.
>

I prefer the consistency of function calls using parenthesis. The
consistent alternative, found in some other languages, is that they
never need parenthesis - "foo a b" calls "foo" with parameters "a" and "b".

(Of course you'd need some syntax for referring to the function itself,
or its address - "fp = &foo;" would not be too onerous, IMHO.)

On Fri, 12 Apr 2024 07:32:33 +0200, Janis Papanagnou wrote:

> Ideally it would be (without syntactic ballast) just
>
> res = func;

Then there is no way to express a reference to the function itself, as
distinct from a call to it.

Unless you do what Algol 68 did, and introduce the “deproceduring
coercion”, analogous to “dereferencing” which allowed doing away with any
explicit “address of x” and “the thingy whose address is in x” constructs.

> (Even Algol 68, where I've seen 'void' mentioned for the first time,
> does not use 'void' for an empty function argument list definition
> or function call.)

I just rechecked the Revised Report (always got to do it before opening my
mouth), and a “statement” is always “strong void”, which means any value
it returns can always be thrown away without having to explicitly say so.

But there are other contexts which are not “strong”, where fewer coercions
happen automatically.

Just did another check, and even in the weakest of syntactic contexts,
“soft”, implicit deproceduring is still allowed (but not implicit
dereferencing).

On 11/04/2024 21:37, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/04/2024 02:18, Lawrence D'Oliveiro wrote:
>>> On Wed, 10 Apr 2024 16:46:43 +0200, David Brown wrote:
>>>
>>>> Just for your entertainment, with C++ lambdas this is now legal code:
>>>>
>>>> void foo(void) {
>>>> [](){}();
>>>> }
>>> C programmer still has habit of writing “(void)” when C++ allows
>>> “()”
>>> instead.
>>
>> I do that sometimes, yes. I could argue that I think it is better to
>> be explicit than implicit, but it's just my fingers on automatic. The
>> kinds of programs I work on can rarely be pure C++ - there's always
>> lots of C code too, and it's often useful to write code in a way that
>> is suitable for both C and C++.
>>
>> In this particular case, of course, there's not much advantage to
>> having a C-style function declaration!
>>
>>> Does the latest C spec now also take “()” to mean “no args”
>>> (synonymous
>>> with “(void)”) instead of “unspecified args”?
>>
>> It does, yes, in C23. If you want to declare a function with no
>> information about the number or type of parameters, you can now write
>> "void foo(...);". (Prior to C23 you needed at least one normal typed
>> parameter before the ellipsis.)
>
> That's not quite the same. (...) declares a variadic function, whose
> arguments (if any) can be accessed using the macros in <stdarg.h>.
> Functions with an old-style () declaration can access their arguments by
> names given in the definition Variadic functions could have a different
> calling convention.
>

Good point. Being able to write "T foo(...)" replaces any need to
declare pre-C23 "T foo()", but it is not a direct replacement without
changing code. (It might work as a replacement in practice for simple
cases, even though it is not required by the C standards - I don't know
how compatible ellipsis arguments are with declared arguments.)

There should, hopefully, be very little code from the last generation
that uses "T foo()" forms other than meaning "T foo(void)".