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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24806 invoked from network); 2 Aug 2023 22:38:14 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2023 22:38:14 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 52B3840FE7; Thu, 3 Aug 2023 08:38:10 +1000 (AEST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by minnie.tuhs.org (Postfix) with ESMTPS id C937940FCF for ; Thu, 3 Aug 2023 08:38:03 +1000 (AEST) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3178dd81ac4so282651f8f.3 for ; Wed, 02 Aug 2023 15:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691015882; x=1691620682; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s160Mx5XNTNk1ofEfjgyyxHOzTFN+r+bJNsuyQUUQks=; b=hz9aKq3bcdtgk1Ty18TVBiR3Ln22SXIrUFgcowYoeb9PY5Ek4k12mM7nmbXCJJUhoy FYCowaVbH8M5m7ajdj8Qj6RGI/aVUEvex3r4gAB1uIf1UGri4ec5ntZsNuCDO/NyBLlF ZEgxlPR8lS8EjDhzDYxHXlPZo7RJkL5y+NRDBiiWq4jsz4hmaP3Odmrmn9dW/nZC4db4 WCCkRuvEwML4lvQ8kDZcagqTbd5xlqc6ONVHgb3oafNMMYBfOwh5lBSUKRSdOCj436H3 YUcnE+u8/Yllp9myMaTPS9IMhaMG5Sj6osnDCmzKJEf1X5VHkDsDtbkzlA/1ulcR2l0Z sOUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691015882; x=1691620682; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s160Mx5XNTNk1ofEfjgyyxHOzTFN+r+bJNsuyQUUQks=; b=a5txpUKzci/nNE7ln0BdjK3zL42iMkeeAbKRaBGDDDErqI6opwH7frykGFDS2Rz9PJ ZHK7V2wK2Z6CchyyWEIVIIyT+MsBbI7Xni1NjQw9NwMT4L1CQ7uR1Bq0n7L0fIzK/wLo G35uCvvHp+3999Ps4aS+4u5aOmf2EMAlx67LrJESYOeNSTx10mR2XdifiS9HaHGf/39W 2KM+Q8RKVzphEqKJhygypkmvqppIg1gZQSG0O6rm9wifiByLFi3GFaQZuUxDlEtfK8Ud 8YkA/V024Dp3wmY1DmJHl84/DmPlz/6ZKTvFtydkz+CAvX+xDKYowwuWgyy4jksDig+r ifdQ== X-Gm-Message-State: ABy/qLb3jwj7v4+poTnQRAXqZPR/1iRxA+uQsAvhXqRQJAwHH+ED2QoX Vw4+6Vc8Zy5ftkG9uDlW/ifFOonMzgu7TxGT+s08yzB4US3D3vwy8Tw= X-Google-Smtp-Source: APBJJlFfZMsP8CWi914fEh5NLOLyDPbJjUvrtt+OG7Pv7eWyAnP10931lCdvDUIT6UdxkJsOcbZ3RvZYfP2VSbDlstI= X-Received: by 2002:adf:f0c9:0:b0:317:66e5:be62 with SMTP id x9-20020adff0c9000000b0031766e5be62mr5836126wro.6.1691015881690; Wed, 02 Aug 2023 15:38:01 -0700 (PDT) MIME-Version: 1.0 References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> In-Reply-To: From: Warner Losh Date: Wed, 2 Aug 2023 16:37:50 -0600 Message-ID: To: segaloco Content-Type: multipart/alternative; boundary="000000000000f030770601f85080" Message-ID-Hash: C662JCH4KXWSIJPUL6GINI3JPEI44DQW X-Message-ID-Hash: C662JCH4KXWSIJPUL6GINI3JPEI44DQW X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Grant Taylor , tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000f030770601f85080 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 2, 2023 at 4:20=E2=80=AFPM segaloco via TUHS wr= ote: > > People think I'm weird for not liking languages that use white space as > > structural definition. > > > > Grant. . . . > > This is my chief gripe with Python, although on the flip side Python isn'= t > the right language anyway for most scenarios where I use > whitespace/indentation to imply structure the language itself can't > articulate. It's meant for mainly functional programming as I understand > it so the structure does enforce some stylistic practices conducive to go= od > functional programming. Still a shame to force a particular style approa= ch > by default rather than just strongly suggest it. > > What strikes me particularly odd about the Python case is that its not > like that space-sensitivity evolved out of the same line of reasoning as > the compulsory spacing in FORTRAN, COBOL, etc. It seems mainly to be a w= ay > to operate without code blocks, with the "blocks" being implied by > indentation rather than braces, parens, or some other delimiter. > > In UNIX of course we have our own little variation on this problem with > make(1) and the need to tab out the rule definition. I seem to recall > reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu > Feldman considered undoing that but there were already users who that > would've caused trouble for, so make's early, entrenched adoption stymied > attempts at the time to rectify this. Anyone with better details feel fr= ee > to correct me. > > - Matt G. > > P.S. This answer can be off list or spin off a separate thread for make > junkies, but did any AT&T or BSD revision of make(1) support rule names > coming from variables rather than explicitly entered? > > For instance: > > $(BIN): $(OBJS) > $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS) > > I used to use this in makefiles but at some point, I think with one of th= e > BSDs, it balked at the idea of a variable rule name and so it fell out of > my practice in trying to avoid GNUisms. > BSD has long supported PROG=3Dcat .include to have it deal with all the details. Of course, FreeBSD's is more complex than that, because nothing is ever simple. And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary. > It's been a while but I feel like I ran through and tried this on V7, > System III, and PDP-11 System V and all of them were unhappy about that > construct. I can try and get on the LCMs 3B400 later to see what SVR3 > does. I don't remember which of the BSDs (if not multiple) I ran into th= at > issue on initially, but I can't imagine one of the major streams would wo= rk > that in without the other two wanting to copy their notes. > They'd likely be happier if you used {} instead of () for variable expansion. > Maybe an alternative question is if folks are aware of make > implementations besides GNU that *do* support that sort of thing. > The NetBSD/FreeBSD pmake does, and has since before NetBSD/FreeBSD were a thing (at least to 4.2BSD, and I think even further back since I'm nearly positive V7 supported it, though I've not cranked up a V7 VM to chek). Warner --000000000000f030770601f85080 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 2, 2023 at 4:20=E2=80=AFP= M segaloco via TUHS <tuhs@tuhs.org&= gt; wrote:
> = People think I'm weird for not liking languages that use white space as=
> structural definition.
>
> Grant. . . .

This is my chief gripe with Python, although on the flip side Python isn= 9;t the right language anyway for most scenarios where I use whitespace/ind= entation to imply structure the language itself can't articulate.=C2=A0= It's meant for mainly functional programming as I understand it so the= structure does enforce some stylistic practices conducive to good function= al programming.=C2=A0 Still a shame to force a particular style approach by= default rather than just strongly suggest it.

What strikes me particularly odd about the Python case is that its not like= that space-sensitivity evolved out of the same line of reasoning as the co= mpulsory spacing in FORTRAN, COBOL, etc.=C2=A0 It seems mainly to be a way = to operate without code blocks, with the "blocks" being implied b= y indentation rather than braces, parens, or some other delimiter.

In UNIX of course we have our own little variation on this problem with mak= e(1) and the need to tab out the rule definition.=C2=A0 I seem to recall re= ading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that S= tu Feldman considered undoing that but there were already users who that wo= uld've caused trouble for, so make's early, entrenched adoption sty= mied attempts at the time to rectify this.=C2=A0 Anyone with better details= feel free to correct me.

- Matt G.

P.S. This answer can be off list or spin off a separate thread for make jun= kies, but did any AT&T or BSD revision of make(1) support rule names co= ming from variables rather than explicitly entered?

For instance:

$(BIN): $(OBJS)
=C2=A0 =C2=A0 $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS)

I used to use this in makefiles but at some point, I think with one of the = BSDs, it balked at the idea of a variable rule name and so it fell out of m= y practice in trying to avoid GNUisms.

= BSD has long supported

PROG=3Dcat

.include <bsd.prog.mk>

to have it deal with all the details. Of course, Fre= eBSD's is more complex than that, because nothing is ever simple.
=

And I think even V7 make supported what you described, = as well as implicit rules for compiling .c into a .o or into a binary.
=C2=A0
It's been a while but I feel like I ran through and tried this on V7, S= ystem III, and PDP-11 System V and all of them were unhappy about that cons= truct.=C2=A0 I can try and get on the LCMs 3B400 later to see what SVR3 doe= s.=C2=A0 I don't remember which of the BSDs (if not multiple) I ran int= o that issue on initially, but I can't imagine one of the major streams= would work that in without the other two wanting to copy their notes.
<= /blockquote>

They'd likely be happier if you used {}= instead of () for variable expansion.
=C2=A0
Maybe an alternative question is if folks are aware of make implementations= besides GNU that *do* support that sort of thing.
The NetBSD/FreeBSD pmake does, and has since before NetBSD/Free= BSD were a thing (at least to 4.2BSD, and I think even further back since I= 'm nearly positive V7 supported it, though I've not cranked up a V7= VM to chek).

Warner=C2=A0
--000000000000f030770601f85080--