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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 475 invoked from network); 11 May 2020 00:44:37 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 11 May 2020 00:44:37 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id B81099C5EC; Mon, 11 May 2020 10:44:35 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 76AF29C2ED; Mon, 11 May 2020 10:44:09 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=yaccman.com header.i=@yaccman.com header.b="IhwqPmmw"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 013F79C2ED; Mon, 11 May 2020 10:44:06 +1000 (AEST) X-Greylist: delayed 957 seconds by postgrey-1.36 at minnie.tuhs.org; Mon, 11 May 2020 10:44:04 AEST Received: from bonobo.birch.relay.mailchannels.net (bonobo.birch.relay.mailchannels.net [23.83.209.22]) by minnie.tuhs.org (Postfix) with ESMTPS id 053339B75D for ; Mon, 11 May 2020 10:44:03 +1000 (AEST) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 597613610BC; Mon, 11 May 2020 00:28:06 +0000 (UTC) Received: from pdx1-sub0-mail-a54.g.dreamhost.com (100-96-14-71.trex.outbound.svc.cluster.local [100.96.14.71]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A3AE9360ACA; Mon, 11 May 2020 00:28:05 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from pdx1-sub0-mail-a54.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Mon, 11 May 2020 00:28:06 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|scj@yaccman.com X-MailChannels-Auth-Id: dreamhost X-Ski-Coil: 431d2d09264450eb_1589156886123_897731975 X-MC-Loop-Signature: 1589156886123:418132367 X-MC-Ingress-Time: 1589156886123 Received: from pdx1-sub0-mail-a54.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a54.g.dreamhost.com (Postfix) with ESMTP id 5247F9BC35; Sun, 10 May 2020 17:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=yaccman.com; h= mime-version:date:from:to:cc:subject:in-reply-to:references :message-id:content-type; s=yaccman.com; bh=FI0se7uvJx33NvUuRO5S HLWx/KQ=; b=IhwqPmmwFSP0yRAxhhR8cKVhIWNfBpYWGREK83Pyz/PxEd7+bLW2 wfOdkJZXvUxZqLQJRvPqcTKh55xs4yw7sceg0V4CU1ryH57cRkLMzwGNQo88Emj2 wnPmkwSI4hiHbVLZWfWoEzTa/qVPBIv1OqozHBNiB1fZsx6Q26/hsCk= Received: from webmail.dreamhost.com (ip-66-33-200-4.dreamhost.com [66.33.200.4]) (Authenticated sender: scj@yaccman.com) by pdx1-sub0-mail-a54.g.dreamhost.com (Postfix) with ESMTPA id C641D9BC36; Sun, 10 May 2020 17:28:04 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 10 May 2020 17:28:04 -0700 X-DH-BACKEND: pdx1-sub0-mail-a54 From: scj@yaccman.com To: Rob Pike In-Reply-To: References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> User-Agent: DreamHost Webmail/1.4.1 Message-ID: <3cb1126796176debe28aa66672ba27ae@yaccman.com> X-Sender: scj@yaccman.com Content-Type: multipart/alternative; boundary="=_bbf98f19993595d0c734b9a6fa0e92ed" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrkeelgdefvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeggfffhvffujghffgfkgigtsegrtdhjredtreejnecuhfhrohhmpehstghjseihrggttghmrghnrdgtohhmnecuggftrfgrthhtvghrnhepheekfeejueeiueeiveevvdfghffgteektedvffetveekjefgkefgveekfeevvdeknecukfhppeeiiedrfeefrddvtddtrdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepfigvsghmrghilhdrughrvggrmhhhohhsthdrtghomhdpihhnvghtpeeiiedrfeefrddvtddtrdegpdhrvghtuhhrnhdqphgrthhhpehstghjseihrggttghmrghnrdgtohhmpdhmrghilhhfrhhomhepshgtjheshigrtggtmhgrnhdrtghomhdpnhhrtghpthhtoheprghksegrkhhkrghrthhikhdrtghomh 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society , ak@akkartik.com Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --=_bbf98f19993595d0c734b9a6fa0e92ed Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Following up on Rob's comment, I always took the point of view that Dennis owned the C description, and what he said goes. Not that I didn't make suggestions that he accepted. One of the better ones (actually in B) was ^ for exclusive OR. One of the worse ones was the syntax for casts. We looked at about 5 different ideas and hated all of them. And most of them couldn't be easily compiled with Yacc. So I took the grammar for declarations, removed the variable name, and voila, it expressed everything we wanted in the way of semantics, had a simple rule of construction, and we badly needed the functionality for the Interdata port. I quickly came to hate it, though -- the casts we were using looked like a teletype threw up in the middle of the code. With respect to enums, there is a feature I've wanted for years: a typed typedef. Saying typetdef int foo would make foo an integer, but if you passed an ordinary int to something declared as foo it would be an error. Even if it was an integer constant unless cast. The amount of mechanism required to get that behavior from both C and C++ is horrible, so far as I know, although C++ has accreted so much stuff maybe it's there now... Steve --- On 2020-04-24 19:54, Rob Pike wrote: > Another debate at the time was caused by a disagreement between pcc and cc regarding enums: are they a type or just a way to declare constant? I remember getting annoyed by pcc not letting me declare a constant with an enum and use it as an int. I protested to scj and dmr and after some to-ing and fro-ing Steve changed pcc to treat them as constants. > > Not sure it was the right decision, but C desperately wanted a non-macro way to define a constant. I'd probably argue the same way today. The real lesson is how propinquity affects progress. > > -rbo > > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike wrote: > The ability to call a function pointer fp with the syntax fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty sure it was not in v7 C, as you observe. > > Convenient though the shorthand may be, it always bothered me as inconsistent and misleading. (I am pretty sure I used it sometimes regardless.) > > -rob > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton wrote: > > On Apr 24, 2020, at 7:37 PM, Charles Anthony wrote: > > On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton wrote: > This doesn't like the function pointer. > > $ cc -c choparg.c > choparg.c:11: Call of non-function > > Perhaps: > > (*fcn)(arg); We have a winner! Also, Kartik, dunno where it is on the net, but if you install a v7 system, /usr/src/cmd/c Adam --=_bbf98f19993595d0c734b9a6fa0e92ed Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Following up on Rob's comment, I always took the point of view that Denn= is owned the C description, and what he said goes.  Not that I didn't = make suggestions that he accepted.  One of the better ones (actually i= n B) was ^ for exclusive OR.  One of the worse ones was the syntax for= casts.  We looked at about 5 different ideas and hated all of them.&n= bsp;  And most of them couldn't be easily compiled with Yacc.  So= I took the grammar for declarations, removed the variable name, and voila,= it expressed everything we wanted in the way of semantics, had a simple ru= le of construction, and we badly needed the functionality for the Interdata= port.   I quickly came to hate it, though -- the casts we were u= sing looked like a teletype threw up in the middle of the code.

With respect to enums, there is a feature I've wanted for years: a typed= typedef.  Saying typetdef int f= oo would make foo an integer, but if you passed an ordinary int to somethin= g declared as foo it would be an error.  Even if it was an integer con= stant unless cast.

The amount of mechanism required to get that behavior from both C and C+= + is horrible, so far as I know, although C++ has accreted so much stuff ma= ybe it's there now...

Steve

---
=  


On 2020-04-24 19:54, Rob Pike wrote:

Another debate at the time was caused by a disagreement be= tween pcc and cc regarding enums: are they a type or just a way to declare = constant? I remember getting annoyed by pcc not letting me declare a consta= nt with an enum and use it as an int. I protested to scj and dmr and after = some to-ing and fro-ing Steve changed pcc to treat them as constants.
 
Not sure it was the right decision, but C desperately wanted a non-mac= ro way to define a constant. I'd probably argue the same way today. The rea= l lesson is how propinquity affects progress.
 
-rbo
 

On Sat, Apr 25, 2020 at 12:51 PM Ro= b Pike <robpike@= gmail.com> wrote:
The ability to call a function pointer fp with the syntax = fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion o= r example. Pretty sure it was not in v7 C, as you observe.
 
Convenient though the shorthand may be, it always bothered me as = inconsistent and misleading. (I am pretty sure I used it sometimes regardle= ss.)
 
-rob
 

On Sat, Apr 25, 2020 at 12:48 PM Ad= am Thornton <a= thornton@gmail.com> wrote:


On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com&= gt; wrote:

 

On Fri, Apr 24, 2020 at 7:00 PM Ada= m Thornton <at= hornton@gmail.com> wrote:
This doesn't like the function pointer.
 
$ cc -c choparg.c<= /div>
choparg.c:11: Call of non= -function
 
Perhaps:
 
    (*fcn)(arg);
 
We have a winner!
 
Also, Kartik, dunno where it is on the net, but if you install a v7 sy= stem, /usr/src/cmd/c
 
Adam
--=_bbf98f19993595d0c734b9a6fa0e92ed--