On Wed, Aug 2, 2023 at 4:20 PM segaloco via TUHS <tuhs@tuhs.org> 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'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 good functional programming.  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 compulsory spacing in FORTRAN, COBOL, etc.  It seems mainly to be a way 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 free 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 the 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=cat

.include <bsd.prog.mk>

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 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.

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