Precedence of juxtaposition qua function application?

[gwhitney]

Similarly to #1007, there doesn't seem to be any discussion in the Reference of the precedence of the "empty operator" meaning function application. As far as I'm concerned, it seems not to bind tightly enough. For example, suppose you see:

a b < c

Which is a better interpretation: a(b) < c or a(b<c) ? I would contend the former is much more common and likely what is intended; I think there are more functions returning things that can be compared than there are functions that take a boolean, in practice. Currently it's interpreted as a(b<c), though.

With some experimentation, it appears that juxtaposition is the lowest possible precedence. I suppose one might argue that this is forced by the fact that a b, c definitely parses as a(b,c) not a(b),c, and comma is the lowest possible precedence operator, so therefore juxtaposition has to be the lowest possible. But I would argue that the comma in a b, c is not the comma operator, but rather a tupling operator, which can and does have different precedence.

Where would I personally put juxtaposition? Looking at the table, the highest line I feel like it should definitely be tighter binding than is relational operators; and the lowest line I feel like it should obviously be looser binding than is exponentiation (a b**2 should be a(b**2). But I think it would be weird for it to break up the set of arithmetic operations (why would a b * c be a(b*c) but a b + c be a(b) + c? So I think it should either go just above or just below the shift operators (I don't use those enough to have any feelings about their precedence). Insofar as shifts are "like" arithmetic, juxtaposition should be looser-binding than shifts.

This whole discussion is about precedence vs operators to the right of juxtaposition, which is unusual in that its precedence differs in the two directions. Versus operators to the left of the juxtaposition, it already has very high precedence; it binds more tightly than new, which is near the top of the hierarchy.

Note that all my suggestions would mean that a b < c, d would parse as a(b) < c, d whereas a b + c, d would parse as a(b+c, d), which I am fine with. If you want a(b<c, d), you can just write that. There are a lot more common situations where parentheses definitely have to be forced, such as a function call as a non-final argument to another function call.

[raythurnvoid]

Another solution may be to disallow all the described cases that are likely to create confusion and force the user to specify the brackets

[gwhitney]

That's a reasonable suggestion. Civet does seem to be dedicated to minimizing the situations in which punctuation is absolutely required, though. So it seems likely that the designers will want Civet to do something in the absence of parentheses, and currently it does do something; I am just commenting on what it would seem (to me) to be the most useful for that something to be.