Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Recursion, Yo
Date: Fri, 12 Apr 2024 14:35:47 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <uvb9r4$2c31v$1@dont-email.me>
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>
 <uv5gfd$qum1$1@dont-email.me> <uv5lgl$s6uj$1@dont-email.me>
 <uv61f6$v1jm$1@dont-email.me> <uv68ok$11080$1@dont-email.me>
 <uv7a8n$18qf8$3@dont-email.me> <uv867l$1j8l6$1@dont-email.me>
 <_zSRN.161297$m4d.144795@fx43.iad> <20240411075825.30@kylheku.com>
 <r8TRN.114606$Wbff.54968@fx37.iad> <uva6ep$24ji7$1@dont-email.me>
 <uvah1j$26gtr$1@dont-email.me> <uvao71$27qit$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 12 Apr 2024 14:35:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e64961bc4a57bf84ee9ec3ae5d82c42";
	logging-data="2493503"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+x1Kytt7l0oxVEaYfCcSSL"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:hubf/47dUTNzhFb++MEf8UxVEgo=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <uvao71$27qit$1@dont-email.me>
Bytes: 3667

On 12.04.2024 09:34, Lawrence D'Oliveiro wrote:
> 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.

It seems that's one of the fundamental differences between (low-level)
languages that want to provide such technical factors explicit to the
user and between languages that want to provide a higher abstraction.

Algol 60, Pascal, Simula 67 and Algol 60, Eiffel, etc. all took that
approach.

Languages syntactically derived from C or borrowed its syntax didn't.

It's, BTW, one of the reasons I like all these languages and not only
from a conceptual point of view, but by far not the only reason; the
way that programmers are not forced to consider low-level technical
stuff but can focus on the algorithm. Some things should be the task
of the compiler, not the programmer. A lot of inherent issues with C
stem from it's low-level design.

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

In Algol 68 everything is an expression. Statements are of type 'void'.
You have, to keep it most simple here, for example,

  PROC f = INT : 3.1415

  PROC p = VOID : SKIP

There's nothing "thrown away" (as in C). This is a completely different
view, and a different path that C has chosen to go, where everything is
a function (as they say).

> [ snip ]

Janis