On Thu, 21 May 2020 at 13:08, Paul Smith <psm...@gnu.org> wrote: > > > Other function syntax where there are "different" types of parameters > > or arguments (i.e. subst, patsubst, findstring, filter, etc.), use a > > syntax something like: > > > > $(math operator, value list) > > > > Consistent syntax patterns are often a plus. ;-) > > Well, we also have functions which don't use a comma: it's used where > needed to make a distinction between "arguments" to the function. If > we ever anticipate having multiple operators (separated by whitespace) > we might want to consider using a comma. > > Otherwise, I'm not sure. It's true that make functions separate using > commas, but on the other hand people used to prefix syntax certainly > won't expect to have to enter an extra comma and will find that very > unusual. >
There's something to be said for this being able potentially to work - not that I'm pushing it mind: FILE_SIZES:= 5 2 1 4 TOTAL:=$(+ $(FILE_SIZES)) # TOTAL is 5+2+1+4 Here I'm not objecting to ($math +,$(FILE_SIZES)) or $(op +,$(FILE_SIZES)) - whatever on them - I am only trying to point out that we naturally iterate over lists of things in make (e.g. of targets or filenames) which are space or tab separated and if you could put a list of numbers into an operation and it just worked it could be quite neat. It would obviously permit some error cases to be expressed which could be undesirable e.g. $(/ 1 2 3) could be a bit ambiguous or at least an unwanted possibility. Regards, Tim
