On Tue, May 19, 2020 at 11:13 AM Paul Smith <psm...@gnu.org> wrote: > > No, I don't like this. Perhaps addition is sufficient for your use- > case but others may need multiplication or division and I certainly > don't want to start adding 10 different explicit funtions like "add", > "mult", etc. I prefer a single mathematical expression function.
I concur with this. > Name: I'm using expr here just for convenience. Is there a better > name? Other than `expr`, maybe `math` or `arith`, but I think at least some people will be familiar with `expr`. Another option would be to introduce some new syntax like $(()), but that might break existing Makefiles and would probably be more work, though it looks cleaner IMO. > Whitespace: do we have to put whitespace around every operator, like > expr(1), or is the function smart enough to understand $(expr 1+1+4)? I think we should go for C-like parsing where the whitespace is insignificant. > Grouping: do we try to implement expression grouping with () (e.g., > $(expr (1 + 1) * 4) or is it good enough to just say people need to > nest expr functions: $(expr $(expr 1 + 1) * 4)? I think nesting `expr` is too noisy. > Precedence: do we try to implement standard mathematical precedence > (multiplication/division before addition/subtraction) or do we just > evaluate left to right and require explicit grouping? It would > definitely be a source of ongoing user confusion to not follow normal > precedence rules, but supporting it would make the implementation more > complex. We should definitely implement the proper precedence. Follow the rules for c? https://en.cppreference.com/w/c/language/operator_precedence I took a programming languages class at University and my professor wrote all of the material for it. Specifically, notes on implementing recursive-descent parsers (hereinafter "RDP") for an interpreted language (which I believe is the type of parsing Make uses). I plan on using this page http://beastie.cs.ua.edu/proglan/expgram.html as a reference for how to accomplish left associativity and the correct presence in a RDP. > Increment/decrement: do we try to implement += / -= and/or ++ --? It > would be something like the symbol on the left would be interpreted as > a variable name, so $(expr foo += 5) would add 5 to the variable foo > (and expand to the new value of $(foo)). If we support ++/-- do we > support both pre- and post- operators? This isn't needed in places > where you can just say "foo = $(expr $(foo) + 5)", but allowing > assignment within an expression could be very helpful. It could be > done anyway with: $(eval foo := $(expr $(foo) + 5))$(foo) ... is it > worthwhile to add syntactic sugar for this? yes assignments as expressions is valuable to make things more readable I think. > If we support increment/decrement do we go farther and support variable > interpolation a la shell $((...)), where a symbol is assumed to be the > value of the variable (that is, $(expr foo + 10) is equivalent to > $(expr $(foo) + 10)? I wouldn't bother implementing this by itself but > it becomes a question if increment/decrement needs it anyway. I don't have a preference on this. Allowing the behavior of $(()) is useful for cutting down on any noisy/messy/extraneous symbols in the argument to $(expr)