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