Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Thu, 11 Jul 2024 11:56:25 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <874j8wkxie.fsf@bsb.me.uk>
References: <v66eci$2qeee$1@dont-email.me> <v6f7vg$hgam$1@dont-email.me>
	<20240707164747.258@kylheku.com> <v6gl83$s72a$1@dont-email.me>
	<v6h8ao$ur1v$1@dont-email.me> <v6jhk3$1drd6$1@dont-email.me>
	<v6jiud$1dsjb$1@dont-email.me> <877cdur1z9.fsf@bsb.me.uk>
	<v6joi4$1epoj$1@dont-email.me> <871q42qy33.fsf@bsb.me.uk>
	<v6k6i0$1h4d3$1@dont-email.me> <87ed82p28y.fsf@bsb.me.uk>
	<v6m03l$1tf05$1@dont-email.me> <87r0c1nzjj.fsf@bsb.me.uk>
	<v6m716$1urj4$1@dont-email.me> <86ikxd8czu.fsf@linuxsc.com>
	<20240710201454.0000527e@yahoo.com> <v6mnch$21n94$1@dont-email.me>
	<20240711111357.00007712@yahoo.com> <20240711012852.856@kylheku.com>
	<20240711121502.0000614e@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 11 Jul 2024 12:56:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8f0c59e317bc680ad3ae1d9bc8fc08f2";
	logging-data="2560939"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18dRfGsFSeZGS90sCiiFUgkRn5zdJ8fKH0="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:MmxAfCB6Sr71QBYMk31u7GlBX8c=
	sha1:1oIXNcTFRs41rMybQOlu8fehGsY=
X-BSB-Auth: 1.715d78222cdc32f35ea9.20240711115625BST.874j8wkxie.fsf@bsb.me.uk
Bytes: 3785

Michael S <already5chosen@yahoo.com> writes:

> On Thu, 11 Jul 2024 08:41:14 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
....
>> First class functions could do something like this:
>> 
>>   // multiplier takes a coefficient and returns a pointer to
>>   // function
>> 
>>   int (*multiplier(int coefficient))(int) {
>>      // fantasy lambda syntax. Return type int is written after
>>      // parameter list.
>>      return lambda(int x) int {
>>         return coefficient * x;
>>      }
>>   }
>> 
>>   int (*doubler)(int) = multiplier(2);
>> 
>>   int x = doubler(42); // x becomes 84
>> 
>> Even though the lambda is returned out of multiplier, whose execution
>> terminates, when the returned function is invoked, it can refer to the
>> coefficient, which is captured in a lexical closure.
>> 
>> With a C-like typedef, we can declutter the definition of mutiplier:
>> 
>>   typedef int (*int_int_fn)(int);
>> 
>>   int_int_fn multiplier(int coefficient) {
>>      return lambda(int x) int {
>>         return coefficient * x;
>>      }
>>   }
>> 
>
> Thank you.
> Your example confirms my suspicion that the difference between first
> and second class of functions doesn't become material until language
> supports closures.

That's half true, but it concentrates on something that is partly
syntactic -- the lexical binding of names.  It possible to do the same
things with no names in sight so the term "closure" would seem rather
odd.  For example, Kaz's example could be written like this is Haskell:

  $ ghci
  GHCi, version 9.4.7: https://www.haskell.org/ghc/  :? for help
  ghci> multiplier = (*)
  ghci> doubler = multiplier 2
  ghci> doubler 42
  84

and, indeed, one way to implement Haskell is is to tranform the code
into combinators.  Combinators were first studied by logicians like
Haskell Curry as a way to re-write formal logics that use quantifiers
(which bind names) into nameless forms.

Of course, "something" is mysteriously doing the same work as the
closures in Kaz's examples, but it not using lexical binding to it.

-- 
Ben.