Fallback to implicit multiplication when function call fails?

[joshop]

I'm not too familiar with how expressions are parsed in numbat, but it would be a lot more ergonomic if an expression like x (y+2), for x and y both scalar constants, was simply evaluated using implicit multiplication once it became clear that a function call wasn't possible. In numbat 1.13 this fails with a constraint error message I don't know how to interpret, in 1.12 it simply tells me "Only functions and function references can be called." I guess this might make parsing tricky, but maybe it could be implemented as allowing primitive types to be "called" and falling through to multiplication there - that might be too much of a hack, though.

[Goju-Ryu]

This also makes the order of precedence confusing as the implicit multiplication should have higher precedence than the explicit one, but with parentheses, the explicit multiplication is required.
I'll also add that a minimal example of this behavior (in the web version) can be produced with simple numbers 2 (4).

[rben01]

I could see a few avenues here:

1. Disallow this completely (current behavior), in which case you can still write (y+2)x
2. Parse a(b) as multiplication when a is a literal but not when it's an identifier
3. Parse a(b) as a function call and a (b) as multiplication
4. Both 2 and 3, so that a(b) is only a function call when a is an identifier and has no space after it

Also for interpreting constraint error messages:

>>> 2(3+4)
error: Could not solve the following constraints:
  Scalar ~ Fn[(Scalar) -> T304]
.. while trying to infer types in the (elaborated) statement:
  2(3 + 4)

This means numbat tried to do type unification to treat 2, a known Scalar, as a function from a Scalar (3+4) to an unknown output type (given the name T304 in my case; I believe it's just a coincidence that it is one character off from T3+4), but this unification, for obvious reasons, failed (a scalar is not a function).

[sharkdp]

it would be a lot more ergonomic if an expression like x (y+2), for x and y both scalar constants, was simply evaluated using implicit multiplication once it became clear that a function call wasn't possible

In general, I agree. I also find myself running into that error.

In numbat 1.13 this fails with a constraint error message I don't know how to interpret

This means numbat tried to do type unification to treat 2, a known Scalar, as a function from a Scalar (3+4) to an unknown output type (given the name T304 in my case; I believe it's just a coincidence that it is one character off from T3+4), but this unification, for obvious reasons, failed (a scalar is not a function).

The interpretation is correct (and T304 is just a generated name with an increasing counter, yes). But @joshop is right. Those constraint solver error messages are horrible. I already reported this as #532. We can't get rid of all constraint solver error messages. But this one can hopefully be avoided (by using our .try_satisfy mechanism, we should be able to immediately see that this constraint can never be fulfilled).

I guess this might make parsing tricky, but maybe it could be implemented as allowing primitive types to be "called" and falling through to multiplication there - that might be too much of a hack, though.

Parse a(b) as multiplication when a is a literal but not when it's an identifier

We can think about it. But I'm generally rather opposed to things like this. I like languages with clear and concise syntax rules, without too much "magic" or "guesswork". I we can rule out that this has unwanted side-effects, we can think about it.

Parse a(b) as a function call and a (b) as multiplication
Both 2 and 3, so that a(b) is only a function call when a is an identifier and has no space after it

Please, no. I don't want the language to have significant whitespace of this kind.

[joshop]

Yeah, I definitely see the conundrum here. I would argue that this one is particularly important, since probably many more users are using implicit multiplication than using function calls in this way. But I agree that I don't really like any of these solutions (including my own).