On 2018-05-21 at 12:17, Kyle Rose wrote: >> On 2018-05-21 at 07:46, Kyle Rose wrote: >>> $(call x) rebinds the positional parameters. $x and $(x) do >>> not. This distinction is used to break macro logic into smaller >>> pieces in which $1 et al. still refer to the positional parameters >>> from the top-level macro instead of being rebound to the empty >>> string. >> >> My suggestion was for only variable names containing a space, so $(x) >> would keep legacy behavior, while $(x y) would work as any function >> call. > > I've had the same thought myself. This would probably work, but it needs to > do something consistent and understandable in cases like these: > > $(fn) <= variable evaluation > $(fn literal) <= macro expansion > $(fn $x) <= macro expansion, even if $x is empty > $(fn ) <= ?? maybe macro expansion?
I think we should ask Paul how did he see it himself. Personally, following the idea of disallowing variable names with spaces (which aren’t easy creating anymore) $(fn ) would stay a variable evaluation, and either we let $(N) be possibly bound to the void string, possibly allowing to be rebound if used in another macro, either we try to unify something by always binding $(0) to the variable name, but then that would break legacy behavior when you compose a macro from several other macros… _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
