search for: fmtspec

...Preudhomme <thomas.preudhomme at linaro.org> wrote: >> >> Hi Alexander, >> >> Please forgive me if I'm missing the obvious but I do not see how the >> order helps allowing a comma in the expression. It seems to me that >> what would allow it is to make FMTSPEC mandatory or at least the comma >> to separate it (ie. [[#,EXPR]] for the default format specifier). In >> any case comma in a function-call like expression can be distinguished >> from comma for the format specifier since one is always inside a >> parenthesized expression....

Hi Alexander, Please forgive me if I'm missing the obvious but I do not see how the order helps allowing a comma in the expression. It seems to me that what would allow it is to make FMTSPEC mandatory or at least the comma to separate it (ie. [[#,EXPR]] for the default format specifier). In any case comma in a function-call like expression can be distinguished from comma for the format specifier since one is always inside a parenthesized expression. That said I don't have a strong...

...g<mailto:thomas.preudhomme at linaro.org>> wrote: >> >> Hi Alexander, >> >> Please forgive me if I'm missing the obvious but I do not see how the >> order helps allowing a comma in the expression. It seems to me that >> what would allow it is to make FMTSPEC mandatory or at least the comma >> to separate it (ie. [[#,EXPR]] for the default format specifier). In >> any case comma in a function-call like expression can be distinguished >> from comma for the format specifier since one is always inside a >> parenthesized expression....

...ote: >> >> >> >> Hi Alexander, >> >> >> >> Please forgive me if I'm missing the obvious but I do not see how the >> >> order helps allowing a comma in the expression. It seems to me that >> >> what would allow it is to make FMTSPEC mandatory or at least the comma >> >> to separate it (ie. [[#,EXPR]] for the default format specifier). In >> >> any case comma in a function-call like expression can be distinguished >> >> from comma for the format specifier since one is always inside a >>...

Hi Alex, Thanks for the feedback. My first thought was that introducing the new pseudo var @EXPR is a nice way to generalize that syntax beyond @LINE since it would also evaluate to an arithmetic value. On the other hand there is a small inconsistency because @LINE evaluates to a value which can be part of an expression while @EXPR is an expression, and so the @ syntax as a whole becomes defined