From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2
Received: (qmail 6990 invoked from network); 25 Apr 2020 18:04:20 -0000
Received: from minnie.tuhs.org (45.79.103.53)
  by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 18:04:20 -0000
Received: by minnie.tuhs.org (Postfix, from userid 112)
	id 0168F9C927; Sun, 26 Apr 2020 04:04:17 +1000 (AEST)
Received: from minnie.tuhs.org (localhost [127.0.0.1])
	by minnie.tuhs.org (Postfix) with ESMTP id CCE309C733;
	Sun, 26 Apr 2020 04:04:00 +1000 (AEST)
Received: by minnie.tuhs.org (Postfix, from userid 112)
 id E82E09C733; Sun, 26 Apr 2020 04:03:58 +1000 (AEST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
 by minnie.tuhs.org (Postfix) with ESMTPS id 8BC749B962
 for <tuhs@tuhs.org>; Sun, 26 Apr 2020 04:03:58 +1000 (AEST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
 id A004918C0B6; Sat, 25 Apr 2020 14:03:57 -0400 (EDT)
To: tuhs@tuhs.org
Message-Id: <20200425180357.A004918C0B6@mercury.lcs.mit.edu>
Date: Sat, 25 Apr 2020 14:03:57 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: Re: [TUHS] v7 K&R C
X-BeenThere: tuhs@minnie.tuhs.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: The Unix Heritage Society mailing list <tuhs.minnie.tuhs.org>
List-Unsubscribe: <https://minnie.tuhs.org/cgi-bin/mailman/options/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=unsubscribe>
List-Archive: <http://minnie.tuhs.org/pipermail/tuhs/>
List-Post: <mailto:tuhs@minnie.tuhs.org>
List-Help: <mailto:tuhs-request@minnie.tuhs.org?subject=help>
List-Subscribe: <https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=subscribe>
Cc: jnc@mercury.lcs.mit.edu
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

    > From: Rob Pike

    > To make chaining of calls simpler. Write
    >   f()->g()->h()->i()
    > the other way

You mean:

  (*f)((*g)((*h)((*i)())))

I dunno, it doesn't seem that much worse to me.


What I like about the explicit notation (i.e. (*f) ()) is that it forces the
programmer to recognize what's going on.

On the other hand, I guess, the whole concept of compiled languages is to get
the programmer's nose out of the low-level details, so they can focus on the
high level. So I guess one could see allowing f() in place of (*f)() as an
instance of that.

Then again, down that road you find a lot of modern code, where a programmer
writes something that is e.g. horribly inefficient and slow, precisely because
they are so divorced from the low-level of what the code they wrote turns into...


Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))),
no matter what the notation was; it would be awfully hard to recognize what
all the possible call chains are. But then again I guess a lot of e.g. AI code
does things like that...

       Noel