From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6115 invoked from network); 8 Jun 2020 15:31:51 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2020 15:31:51 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 343D69C86C; Tue, 9 Jun 2020 01:31:48 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2F7309C5F8; Tue, 9 Jun 2020 01:31:30 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XONJQn3Y"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 530B69C5F8; Tue, 9 Jun 2020 01:31:28 +1000 (AEST) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by minnie.tuhs.org (Postfix) with ESMTPS id C551A9C5E5 for ; Tue, 9 Jun 2020 01:31:27 +1000 (AEST) Received: by mail-qk1-f177.google.com with SMTP id c185so17615582qke.7 for ; Mon, 08 Jun 2020 08:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=poJSPPvmpo3bO1ISxWsrTEOCUZ1utA0/Qxn9pcqUOhU=; b=XONJQn3YIwXVbGhc5atU5uc27vctB5z1aANtdX3W3gR+lhsXEQXp8OsE5AwKtueMu/ iXpZpAsZZalbPe0n0SHKtUFGtds5se3MBrOqbkq9/Oc4WttcKvFcAjAm1rjy2O1OfZI3 2peuCOgIwYVuvKg2bHMnQcXjq4XtrKglNQvRd1J+wCN3pgdx23K5KNxwXgNWmddkMSCI gZsx6GXPedK7mtRo36raXu/XEdSRV6mj6H+nG+E5TCqangb630b2FsQQbIhcorsR2v9J EGpNdK98FWF/3NP+2RNSl0oIFZqWnqB2J8xs22OR3vwp5xHI82dzb7sYNq65PFeJEiGq rDTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=poJSPPvmpo3bO1ISxWsrTEOCUZ1utA0/Qxn9pcqUOhU=; b=Ef6o1D5dRWgb+ZfMrnYI+Fuj1dZeFoUEUV6n+k0MPqYOMN2Mz7+ecJwSfrYy68nSqY lN3/KHPTn9U9rswOXuuBeoiKuNQL18c4/YXLNeXFbh7cfDWcmnQLYZwIs7TuUA4WE12+ hjOxsYuo4EdLivgJs2A+JzJo6IQsNmCL1ECiI2Rfm6zDjwmE+MYJOX32YSc+yimYUQBn eBoQbhXBnR7Uec+3KY6GP307okoz0AiJKRv6+GfDIRZS+9QvUV5zS0nMlGWQqJ4OGAE4 pFXmtefoZuJkmCAhU/zMlg8nVqAmqkAQySOUxotwYQaJqsb/HNTyAfNOwW3xuD7SuKqF Wu/w== X-Gm-Message-State: AOAM530OyJqWJizzJRNBoMlS5zXiGnBf7I+t1YJGmrBZR9HKYv03ugmS der69bQB32TlL68E2zE6Q53RqDo8HwcIq7z6unNFhi6h X-Google-Smtp-Source: ABdhPJx/FKlZgNMojLImN7DpW1jSD69OHUOMNaHU6+/9R5i2jXaciHrin6Busx99RACsxaGkxW5j07S/E6dY4bDLdxM= X-Received: by 2002:a37:ac03:: with SMTP id e3mr22763570qkm.350.1591630287000; Mon, 08 Jun 2020 08:31:27 -0700 (PDT) MIME-Version: 1.0 References: <202006062149.056LnNsb074899@tahoe.cs.Dartmouth.EDU> In-Reply-To: <202006062149.056LnNsb074899@tahoe.cs.Dartmouth.EDU> From: Dan Cross Date: Mon, 8 Jun 2020 11:30:50 -0400 Message-ID: To: Doug McIlroy Content-Type: multipart/alternative; boundary="000000000000ded73505a7944dbe" Subject: Re: [TUHS] History of popularity of C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000ded73505a7944dbe Content-Type: text/plain; charset="UTF-8" On Sat, Jun 6, 2020 at 5:50 PM Doug McIlroy wrote: > > Steve Johnson's position paper on optimising compilers may amuse you: > > https://dl.acm.org/doi/abs/10.1145/567532.567542 > > Indeed. This passage struck a particular chord: > > "I contend that the class of applications that depend on, for example, loop > optimization and dead code elimination for their efficient solution is of > modest size, growing smaller, and often very susceptible to expression in > applicative languages where the optimization is built into the individual > applicative operators." > > I don't know whether I saw that note at the time, but since then I've > come to believe, particularly in regard to C, that one case of dead-code > elmination should be guaranteed. That case is if(0), where 0 is the > value of a constant expression. > > This guarantee would take the place of many--possibly even > most--ifdefs. Every ifdef is an ugly intrusion and a pain to read. > Syntactically it occurs at top level completely out of sync with the > indentation and flow of text. Conversion to if would be a big win. > This came up on this list back in 2017 and I posted something about this at the time: https://minnie.tuhs.org/pipermail/tuhs/2017-January/009325.html If the language had been extended to support a "compile-type conditional" syntax ("if #(LINUX)", for example) it would have obviated the need for most preprocessor conditionals. As long as, syntactically, the compiler could tokenize a block in absence of e.g. type definitions, dead-code elimination could do the job. - Dan C. --000000000000ded73505a7944dbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 6, 2020 at 5= :50 PM Doug McIlroy <doug@cs.da= rtmouth.edu> wrote:
> Steve Johnson's position pap= er on optimising compilers may amuse you:
> https://dl.acm.org/doi/abs/10.1145/567532.56754= 2

Indeed. This passage struck a particular chord:

"I contend that the class of applications that depend on, for example,= loop
optimization and dead code elimination for their efficient solution is of modest size, growing smaller, and often very susceptible to expression in applicative languages where the optimization is built into the individual applicative operators."

I don't know whether I saw that note at the time, but since then I'= ve
come to believe, particularly in regard to C, that one case of dead-code elmination should be guaranteed. That case is if(0), where 0 is the
value of a constant expression.

This guarantee would take the place of many--possibly even
most--ifdefs. Every ifdef is an ugly intrusion and a pain to read.
Syntactically it occurs at top level completely out of sync with the
indentation and flow of text. Conversion to if would be a big win.

This came up on this list back in 2017 and I po= sted something about this at the time:


If the language had been extended to support a "compile-type c= onditional" syntax ("if #(LINUX)", for example) it would hav= e obviated the need for most preprocessor conditionals. As long as, syntact= ically, the compiler could tokenize a block in absence of e.g. type definit= ions, dead-code elimination could do the job.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--000000000000ded73505a7944dbe--