On Mon, 2020-05-25 at 12:07 -0400, Sam Kendall wrote: > I'd like to raise some questions that I think any proposal ought to > answer. I'll assume a straw man proposal: there's one function, and > it takes one of the following forms: > > $(math OPERATOR,VALUE1,VALUE2) > $(math OPERATOR,VALUE1)
I believe the form being considered is: $(math OPERATOR,LIST) where LIST expands to a space-separated list of integer values. The operator is applied to the entire list, from left to right. > A binary operator (first form) is one of + - * and /. The only unary > operator is "-". Negation (unary "-") is definitely a problem since unfortunately standard math uses the same symbol for negation and subtraction. I don't want to use the OPERATOR (in the above form) to handle it, because I don't want to have $(math -,2) behave differently from $(math -,2 0): it's too bizarre and confusing. I'd prefer to see it allowed in the parsing of LIST, and handled there. This absolutely needs thought and needs to be in the proposal. > There might also be equality and relational operators. A value is an > optional "-" followed by one or more decimal digits. It represents a > 64-bit signed integer. If negation is handled during LIST parsing then we need to allow multiple initial "-", so you can say "-$(foo)" where $(foo) is -5. This does mean that we wouldn't support "--"/"++" operators. For all your other questions I agree the proposal needs to address them. I agree with you that all invalid operations should yield fatal errors. The only one I'm not sure about is overflow. That will need some thought. Gnulib contains a comprehensive set of macros to deal with overflow, in various ways.