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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31549 invoked from network); 11 May 2020 00:32:49 -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:32:49 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 6FA809C2EF; Mon, 11 May 2020 10:32:47 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0B8E49C2ED; Mon, 11 May 2020 10:32:17 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="oAFZwBpa"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6A8D29C2ED; Mon, 11 May 2020 10:32:14 +1000 (AEST) Received: from mail-ua1-f65.google.com (mail-ua1-f65.google.com [209.85.222.65]) by minnie.tuhs.org (Postfix) with ESMTPS id C83009B75D for ; Mon, 11 May 2020 10:32:13 +1000 (AEST) Received: by mail-ua1-f65.google.com with SMTP id k13so2414343uap.13 for ; Sun, 10 May 2020 17:32:13 -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=I/ePq15QRh7EqnyYzu/cMD1gn5znIf7va0RJnOHzz4k=; b=oAFZwBpaAjNk0bYfpu/RzBWr9L5xsQcXELyFYp9stCiRJmAvnZiFMlMI7BU3MRge/t 7kRMu+uuHITescfiFohK8LzixiCqlMpRVjOUMonTxM8frqD6VWcpJScwCqNDJ0j2Jkpg 5ov+D0uDqkSl+rDtPNZypcO5BSuGWs6huOdGz7Hcva8wqLiYbaG6i3VmdS6GKIkOaW8a GCn6cskKuc+0hbSbEuifDVuIVtUFAwaFCRH7d9Mb3He48XhTP5So8LXOsg4O0VJEbmni pi0FRL+Wg6jrVIWEGokZ+TkWLsyaw2FovzNAAURYRgtTExVwOPY4O9M/33J+btSyeFDd UpVg== 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=I/ePq15QRh7EqnyYzu/cMD1gn5znIf7va0RJnOHzz4k=; b=FZjplfHSX7+fKbyd7+ZWc0iucjOOxtWOgDDQV6kxLL9UIKv0k2NCq1Mq+ukFwV3hbS x9ePVTogT+KHlTyQnCHEQB37Zj3IPsWjCOuoZj9rxmvqnnf+T9HIC4CI0RncKePv1VUG Ilw/gBcb0AfkDrC+6RL5cGOcS3OOGuCtW8X8CDBMYKTeCZ9+TCCxsVKvVNQN5v34fgKs U6rova+d7BcNP0R8SyFAr1DTQlaTEuYkxVTqPwJWpKg+KLofS3LeJWHtBnimbpkXZWuW aK8S0lXN/Qs6co5UMvpocMDay+DYFRJ75xVuKoVsuh/B+gK8rDlDW3ixFBFB7Tlhmfxs e7FA== X-Gm-Message-State: AGi0PuaoblPx7IgL/bTgYqXgE8ZP6VCFUuF27OIUTWMo/n+EaehlMbbG GzSQguIg/lD4NK38d8K8rOS4I0fONLNScWc8uNA= X-Google-Smtp-Source: APiQypJfH2zU/8IUb/fbsCB2oirVfe2aw7f4XeXJDbYwfAVoT3T+3rZDUTKUwbOBnoSk/3/n11gj/FqYfI/tKk0zOaQ= X-Received: by 2002:ab0:5642:: with SMTP id z2mr9599611uaa.6.1589157132771; Sun, 10 May 2020 17:32:12 -0700 (PDT) MIME-Version: 1.0 References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <3cb1126796176debe28aa66672ba27ae@yaccman.com> In-Reply-To: <3cb1126796176debe28aa66672ba27ae@yaccman.com> From: Rob Pike Date: Mon, 11 May 2020 10:32:01 +1000 Message-ID: To: Steve Johnson Content-Type: multipart/alternative; boundary="00000000000064259c05a5547a7a" 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" --00000000000064259c05a5547a7a Content-Type: text/plain; charset="UTF-8" Interesting that Go had only what you call "typed typdefs" until we needed to add "untyped typedefs" so we could provide aliasing for forwarding declarations. And that necessity made me unhappy. But the short version: Go went the other way with what "typedef" means. -rob On Mon, May 11, 2020 at 10:28 AM wrote: > 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 > > --00000000000064259c05a5547a7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting that Go had only what you call "typed typ= defs" until we needed to add "untyped typedefs" so we could = provide aliasing for forwarding declarations. And that necessity made me un= happy. But the short version: Go went the other way with what "typedef= " means.

-rob


On Mon, May 11, 2= 020 at 10:28 AM <scj@yaccman.com&= gt; wrote:

Following up on Rob's comment, I always took the point of view that = Dennis owned the C description, and what he said goes.=C2=A0 Not that I did= n't make suggestions that he accepted.=C2=A0 One of the better ones (ac= tually in B) was ^ for exclusive OR.=C2=A0 One of the worse ones was the sy= ntax for casts.=C2=A0 We looked at about 5 different ideas and hated all of= them.=C2=A0 =C2=A0And most of them couldn't be easily compiled with Ya= cc.=C2=A0 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 t= he Interdata port.=C2=A0 =C2=A0I quickly came to hate it, though -- the cas= ts 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 t= yped typedef.=C2=A0 Saying=C2=A0typetdef int= foo would make foo an integer, but if you passed an ordinary int to someth= ing declared as foo it would be an error.=C2=A0 Even if it was an integer c= onstant 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

---
=C2=A0


On 2020-04-24 19:54, Rob P= ike 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.
=C2=A0
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= real lesson is how propinquity affects progress.
=C2=A0
-rbo
=C2=A0

On Sat, Apr 25, 2020 at 12:51 PM Rob 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 suggesti= on or example. Pretty sure it was not in v7 C, as you observe.
=C2=A0
Convenient though the shorthand may be, it always bothered=C2=A0me as = inconsistent and misleading. (I am pretty sure I used it sometimes regardle= ss.)
=C2=A0
-rob
=C2=A0

On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athorn= ton@gmail.com> wrote:


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

=C2=A0

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