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 11171 invoked from network); 11 May 2020 02:17:10 -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 02:17:10 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id F11F59C5E9; Mon, 11 May 2020 12:17:05 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id BCC2A9C2ED; Mon, 11 May 2020 12:16:29 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=serissa.com header.i=@serissa.com header.b="TvC7bpiU"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="cDQLRJH6"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 98A689C2ED; Mon, 11 May 2020 12:16:26 +1000 (AEST) X-Greylist: delayed 443 seconds by postgrey-1.36 at minnie.tuhs.org; Mon, 11 May 2020 12:16:25 AEST Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by minnie.tuhs.org (Postfix) with ESMTPS id 754A49B75D for ; Mon, 11 May 2020 12:16:25 +1000 (AEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7189B3C4; Sun, 10 May 2020 22:09:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 10 May 2020 22:09:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=serissa.com; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=MwjQOYEqO44nh//fe2bHp1q XMjqR89/umRmJce8wB/8=; b=TvC7bpiUNNC4rHjFA0I3K7mRe7Gj5VqwQTuBW+j Yl+kDTWPnEoz+rOIOg8qJLCCTnZfjaQNyN8ZbgoNXJr8IFW+IsAsohwnsWi0Z4R1 Gf0HS7LAf2Epp8twuY4VQy2dPCCOHCFSpj+cVN8Gxed2zviIjJAw5es2tnYntYv2 +liVXE4l9+WeOAkzG34rAXuyyafa5TETnAdMS4pIOm58bL8M4gKAYmEhMXpDgw0w IW3htF8gLdSne1TM+rZactaMh4iChYa2nXAWL/8oB2vCH0hgjiyMvkCfgOeUnpMa qV7EnrdqUFYNQ3TbbnWR6CQTpY5ytOZl3qK/xy5bH85SpZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MwjQOY EqO44nh//fe2bHp1qXMjqR89/umRmJce8wB/8=; b=cDQLRJH6HOfFg1QQHEZSJW 2oYgJKOS1M7PaF2C+ufcYPUWM6MrqxhXURQ7E4sUSsdp+IxjABkKrlEjXlE+oPby g5NtoZ1t5a2+0mnJjKRiNHdam950eQBZts+P5WUIXeYAw3vGKAXpn/z40RowQHVr UwE/o//EeUm3JLf/i8uMwqMfMc2hmIBbPhoNrqmwW1eZ4upHmtI9ofhInGWIkK3x kjtLNNgA6019A3sPQ+KqCez9s5X/6htRJMVaLDwu5JcI7DFmIUQFY57H32tZIciU EXPoGrcTV7kTo4nbj35N1n5LsWurNkz7h1K/AKrut9kNvYTTUYM1GJIYLfrr+oOA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeelgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomhepnfgrfihrvghn tggvucfuthgvfigrrhhtuceoshhtvgifrghrthesshgvrhhishhsrgdrtghomheqnecugg ftrfgrthhtvghrnhepudevgfdvhfeikeehhfekjeduvdefueetueelvdevvedttdefleeg uddvudfgheffnecuffhomhgrihhnpegsihhtshgrvhgvrhhsrdhorhhgnecukfhppeduje efrdegkedrheehrdegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehsthgvfigrrhhtsehsvghrihhsshgrrdgtohhm X-ME-Proxy: Received: from kailua-display.stewart.org (pool-173-48-55-45.bstnma.fios.verizon.net [173.48.55.45]) by mail.messagingengine.com (Postfix) with ESMTPA id BD5A0306627C; Sun, 10 May 2020 22:08:59 -0400 (EDT) From: Lawrence Stewart Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A6FD3C78-610C-4A59-BA53-4F101B7AB20B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 10 May 2020 22:08:58 -0400 In-Reply-To: <3cb1126796176debe28aa66672ba27ae@yaccman.com> To: Steve Johnson References: <6D6EFA0C-36C3-4225-A331-D1998A07C50A@gmail.com> <3cb1126796176debe28aa66672ba27ae@yaccman.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) 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" --Apple-Mail=_A6FD3C78-610C-4A59-BA53-4F101B7AB20B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If I remember correctly, enums in Mesa (the PARC Pascal like system = language) had typed enums. The 1979 version of the language manual at = http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language= _Manual_Version_5.0.pdf = says so anyway. -L PS The niftiest use of #define I know about was at the short lived = supercomputer company SiCortex around 2005. Wilson Snyder (verilator = fame) wrote a thing that extracted all the constants and register = definitions from the CPU chip spec and output them as #define = equivalents in 5 different languages. PPS Thank you for =E2=80=98^' > On 2020, May 10, at 8:28 PM, scj@yaccman.com wrote: >=20 > 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. >=20 > 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. >=20 > 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... >=20 > Steve >=20 > --- > =20 >=20 >=20 > On 2020-04-24 19:54, Rob Pike wrote: >=20 >> 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. >> =20 >> 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. >> =20 >> -rbo >> =20 >>=20 >> 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. >> =20 >> Convenient though the shorthand may be, it always bothered me as = inconsistent and misleading. (I am pretty sure I used it sometimes = regardless.) >> =20 >> -rob >> =20 >>=20 >> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton > wrote: >>=20 >>=20 >>> On Apr 24, 2020, at 7:37 PM, Charles Anthony = > wrote: >>>=20 >>> =20 >>>=20 >>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton > wrote: >>> This doesn't like the function pointer. >>> =20 >>> $ cc -c choparg.c >>> choparg.c:11: Call of non-function >>> =20 >>> Perhaps: >>> =20 >>> (*fcn)(arg); >>> =20 >>=20 >> We have a winner! >> =20 >> Also, Kartik, dunno where it is on the net, but if you install a v7 = system, /usr/src/cmd/c >> =20 >> Adam --Apple-Mail=_A6FD3C78-610C-4A59-BA53-4F101B7AB20B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = I remember correctly, enums in Mesa (the PARC Pascal like system = language) had typed enums.
The 1979 version of the = language manual at http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Me= sa_Language_Manual_Version_5.0.pdf
says so = anyway.
-L

PS  The niftiest use of #define I = know about was at the short lived supercomputer company SiCortex around = 2005.  Wilson Snyder (verilator fame) wrote a thing that extracted = all the constants and register definitions from the CPU chip spec and = output them as #define equivalents in 5 different languages.

PPS Thank you for = =E2=80=98^'

On 2020, May 10, at 8:28 PM, scj@yaccman.com = 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 <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 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 <athornton@gmail.com> wrote:


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

 

On Fri, Apr 24, 2020 at 7:00 PM = Adam Thornton <athornton@gmail.com> 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

= --Apple-Mail=_A6FD3C78-610C-4A59-BA53-4F101B7AB20B--