>From: Kaz Kylheku (gmake) <[email protected]> >On 2021-01-22 13:18, Cook, Malcolm wrote: >> Hi Paul et. al., >> >> When a rule has multiple prerequisites I sometimes use make variables >> to refer to them positionally, like this: >> >> ^1=$(word 1,$^) >> ^2=$(word 2,$^) >> ^3=$(word 3,$^) >> ^2..=$(wordlist 2,$(words $^),$^) >> ^3..=$(wordlist 3,$(words $^),$^) >> >> %.foo: %.bar %.baz %.bat1 %.bat2 %.bat3 >> process --baz ${^2}--bar ${^1} --bat ${^3..} > $@ >> >> What do you think of such syntactic sugar? > >Arguments in macros are already $(1), $(2). (But those were used, it >would cause "optical difficulties" in rules generated by macros.)
Yes, I am aware. I do not use the above in any way with macros, but rather within rule bodies. > >Speaking of macros, the above can be achieved very verbosely now using >call: > >prereq = $(word $(1),$^) > >$(call prereq 3) # -> $(word 3,$^) Yes, of course, but the verbosity is not satisfying... using such would not make rules scan better, whereas what I do already feels familiar in that it introduces a convention similar to standard positional argument access in many scripting environments. > >Firstly, it would be nice if macros with arguments could be invoked >without the clunky $(call). I have often felt similarly, but this is really a separate issue from mine.... > >I propose this syntax: >For instance, the syntax > >$(prereq) # straight old substitution with no args >$(prereq 3) # == $(call prereq,3): substitution with $(1) = 3. > >Additional arguments use commas > >$(foo 1,2,3) # $(call foo,1,2,3) > >Now, if we define a one-letter macro, like $(p 3), we have good density. > >A further abbreviation facility could then perhaps be developed which >binds dispatch characters to macros so that $(^3) can become $(prereq >3). That only saves one >space over $(p 3) though. > >Of course, without $(call ...), macros now clash in the namespace of >predefined operators. >If someone does this: > >word = whatever > >$(word 1,abc def) # this is the built-in, not a call of the above >word > >Makefiles then run the risk of breaking because they >used some word that is later claimed as a new built-in by >a new version of GNU Make. Some namespace rules could be documented. >For instance, no built-ins start with a capital letter currently >and future ones likely won't also, so that seems like a safe space >for defining macros. Such names clash with the reserved environment >space in POSIX, though. > >Another idea might be to have some shorthand for $(call ...) like >say $[abc x,y,z,...] <--> $(call abc,x,y,z,...). > >That's eerily like what I did in TXR Lisp. > >1> '(dwim f x y z) >[f x y z] >2> (car '[f x y z]) >dwim >3> (cdr '[f x y z]) >(f x y z) >4> > > >dwim is a special dispatching operator whose name you almost never >directly mention in any conceivable code due to the [ ] shorthand. >It calls functions, accesses hashes, indexes into sequences like >lists vectors and strings and also allows for LIsp-1 style >programming in a dialect that is fundamentally Lisp-2 (separate >variable and function namespace). > >E.g. (mapcar cons '(1 2 3) '(a b c)) won't work, because there >is no cons variable, but [mapcar cons '(1 2 3) '(a b c)] >will, because of a name lookup semantics alteration imposed by >the dwim operator. > >But I digress. > Hah. Brings back fond memories...I first came across dwim on Xerox Dandylion lisp machines in the 1980s. Those machines were a joy to work on, but I preferred working on the Symbolics 3600 I "cut my teeth" on. But *I* digress. Thanks for your thoughts, Malcolm
