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,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24343 invoked from network); 2 Aug 2023 22:20:33 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2023 22:20:33 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7BA9040FF2; Thu, 3 Aug 2023 08:20:28 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1691014828; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=1lh9REpZB505LCJQwqlJTMUPNG1WRaWiWFNbYErarFk=; b=gWVPO2mMYghODnpT2+C/+CSLcr48TqfEPhXFLIstNQwiSR50vLdfTqlJOkTYcHxk548APR SG6TNWItEKznb+NvI+B89Rdkk6mVo/frbIKJeCCwiaZEFUPL3NArwkxVaFrILgWG0ynEqH oSKfyGL3h7l2tWlBEvQK1gkb6LPcjuk= Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by minnie.tuhs.org (Postfix) with ESMTPS id 1B16740FE8 for ; Thu, 3 Aug 2023 08:20:24 +1000 (AEST) Date: Wed, 02 Aug 2023 22:20:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1691014821; x=1691274021; bh=1lh9REpZB505LCJQwqlJTMUPNG1WRaWiWFNbYErarFk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=zZzEpqwKGQIha38sRimW9BnFCNJTfOVRLotzGped6e5/prHce1qQG3n+qZi3o47cQ r/UW6J8BRCQZlS4niaV6jfo1W4kG79p6bZEd/5JH6eg0JzhVNYzvmmzdAXD6Zv9+gm b3SLaxwRuPO4uON1xTcO1rmEu81VMHNnwWlsTdVsGD6PWlzDil0xEZhHjZi96WY5eA lnP5D7SBEtdcTLzFBoGASuchHdR0Twy+QnOgI6nn3p/2PSn/kMvh9Acnh3CPH9XTtw TjbaLo0H32o8wYHJLpapJCXDZmi+BlDCSvUu20HbA6rAvdMUJXEPtIQvQFTUDJxzj+ qsWN2ya3xk7jw== To: Grant Taylor Message-ID: In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ZWFS4STBCEGBSDQF4ZLTZLPBWKLOKULX X-Message-ID-Hash: ZWFS4STBCEGBSDQF4ZLTZLPBWKLOKULX X-MailFrom: segaloco@protonmail.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: 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: From: segaloco via TUHS Reply-To: segaloco > 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/indenta= tion to imply structure the language itself can't articulate. It's meant f= or mainly functional programming as I understand it so the structure does e= nforce some stylistic practices conducive to good functional programming. = Still a shame to force a particular style approach by default rather than j= ust 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. It seems mainly to be a way to op= erate without code blocks, with the "blocks" being implied by indentation r= ather 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. I seem to recall reading= somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu Feldman co= nsidered 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 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 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 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. It's been a while but I feel like I ran through and tried this on V7, Syste= m III, and PDP-11 System V and all of them were unhappy about that construc= t. 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 that issue on in= itially, but I can't imagine one of the major streams would work that in wi= thout the other two wanting to copy their notes. Maybe an alternative question is if folks are aware of make implementations= besides GNU that *do* support that sort of thing.