On Wed, Aug 2, 2023 at 4:20 PM segaloco via TUHS <tuhs(a)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