Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Recursion, Yo
Date: Wed, 10 Apr 2024 17:10:40 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <20240410063255.565@kylheku.com>
References: <uut24f$2icpb$1@dont-email.me> <uutqd2$bhl0$1@i2pn2.org>
 <uv2u2a$41j5$1@dont-email.me> <87edbestmg.fsf@bsb.me.uk>
 <uv4r9e$mdd3$1@dont-email.me> <uv5e3l$q885$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 10 Apr 2024 19:10:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a02df6af16e190f6c7ee895d512b8f84";
	logging-data="1151493"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18iNroKgaxamAlKQa3SGLIr1Ph4pcdOAFo="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:RwUxmemz6V7G1pQXQWyaHm99AYI=
Bytes: 4419

On 2024-04-10, David Brown <david.brown@hesbynett.no> wrote:
> On 10/04/2024 03:50, Lawrence D'Oliveiro wrote:
>> On Tue, 09 Apr 2024 11:44:23 +0100, Ben Bacarisse wrote:
>> 
>>> It's significant (or at least note worthy) that the code in the
>>> original post was not ISO C ...
>> 
>> Interesting that GCC’s C compiler allows nested routine definitions,
>> but the C++ compiler does not.
>
> It is an old extension, going back to when gcc barely (if at all) 
> supported C++.  The compiler middle-end had to have support for nested 
> functions for languages like Pascal, Module 2 and Ada (I believe Ada is 
> the only one of these that stuck around in gcc mainline, but other 
> language front-ends have been made outside the main tree).  Someone 
> thought it might be a useful feature in C too, and perhaps something 
> that would catch on in the standards (several early gcc extensions ended 
> up standardised in C99).
>
> It is not much used in practice, AFAIK.  For some cases the code 
> generation for nested functions was fine and straight-forward.  In other 
> cases, however, it required a trampoline generated on the stack, and 
> that became a real pain once non-executable stacks came into fashion.
>
> Nested functions were never as interesting for C++ as you already have 
> better mechanisms for controlling scope and data access - classes and 
> their methods, including nested classes.  And once lambdas joined the 

Higher level languages like Common Lisp show that you want both;
even though theoretically you can implement OOP with lambdas, or
simulate some aspects of lambdas with OOP (particularly if your OOP
supports callable objects).

> party in C++11 there was absolutely no reason to have nested functions - 
> there is nothing (AFAIK) that you could do with nested functions that 
> you can't do at least as well, and often better, with lambdas.

GNU C nested functions don't require any special syntax (other than teh
fact of allowing a function definition inside a statement block). They
implicitly capture the actual variables in the surrounding scope using
ordinary C function syntax.

The address of a GNU C nested function is regular function pointer;
you can pass it to qsort and bsearch.

In fact, you can pass a GNU C nested function into a library that was
not even compiled with GCC. If it understand the calling conventions of
function pointers, it can call the function.

However, GNU C nested functions are "downward funarg" only, which
is a pretty severe limitation. (Worse, GNU C nested function can
escape from a scope in spite of being dowward funarg only,
causing undefined behavior when they are called.)

(The "downward funarg" terminology is from ancient Lisp or Algol
literature, means "downward (only) functional argument": a function that
can be used as an argument to function, but not returned; i.e. passed
downward only.)

The downward funarg restriction has benefits too; such functions do not
require any dynamic allocation at all. The closed-over variables are
referenced directly in their still-living stack frame.

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