Add syntax for implicit coefficients

[evhub]

Should compile

5 x**2 + 2 x

to

5 * x**2 + 2 * x

The biggest problem, unfortunately, is that this would have a different precedence than implicit function application f x currently has, since

a x**2 + b x

is currently valid and compiles to

a(x)**2 + b(x)

Probably, the best way to do this is to change the precedence of implicit function application to be just tighter than */@ and have implicit function application check if the function is an int/float/numpy dtype and in that case use multiplication rather than function application. However, this would be a breaking change.

[evhub]

Current operator precedence table:

====================== ==========================
Symbol(s)              Associativity
====================== ==========================
f x                    n/a
await x                n/a
..                     n/a
**                     right
+, -, ~                unary
*, /, //, %, @         left
+, -                   left
<<, >>                 left
&                      left
^                      left
|                      left
::                     n/a (lazy)
a `b` c,               left (captures lambda)
  all custom operators
??                     left (short-circuits)
..>, <.., ..*>, <*..,  n/a (captures lambda)
  ..**>, <**..
|>, <|, |*>, <*|,      left (captures lambda)
  |**>, <**|
==, !=, <, >,
  <=, >=,
  in, not in,
  is, is not           n/a
not                    unary
and                    left (short-circuits)
or                     left (short-circuits)
x if c else y,         ternary left (short-circuits)
  if c then x else y
->                     right
====================== ==========================

New operator precedence table after this change:

====================== ==========================
Symbol(s)              Associativity
====================== ==========================
await x                n/a
**                     right
f x                    n/a
+, -, ~                unary
..                     n/a
*, /, //, %, @         left
+, -                   left
<<, >>                 left
&                      left
^                      left
|                      left
::                     n/a (lazy)
a `b` c,               left (captures lambda)
  all custom operators
??                     left (short-circuits)
..>, <.., ..*>, <*..,  n/a (captures lambda)
  ..**>, <**..
|>, <|, |*>, <*|,      left (captures lambda)
  |**>, <**|
==, !=, <, >,
  <=, >=,
  in, not in,
  is, is not           n/a
not                    unary
and                    left (short-circuits)
or                     left (short-circuits)
x if c else y,         ternary left (short-circuits)
  if c then x else y
->                     right
====================== ==========================

[evhub]

If we do this, we should probably add a warning if we detect

f x ** y

since it'll change meaning from f(x)**y to f(x**y).

[evhub]

Problem—what are we supposed to do with this:

f a b ** +c d

Presumably it should go to:

f(a, b ** +c, d)

Also, what about:

a ** b c

Presumably that's a parse error?

[evhub]

While we're at it, maybe we should also substantially decrease the precedence of .., since right now it's totally useless to have it higher than all the arithmetic operators, since we know they'll always result in an error when called on a function composition. Thus, new proposed precedence table is:

====================== ==========================
Symbol(s)              Associativity
====================== ==========================
await x                n/a
**                     right
f x                    n/a
+, -, ~                unary
*, /, //, %, @         left
+, -                   left
<<, >>                 left
&                      left
^                      left
|                      left
::                     n/a (lazy)
..                     n/a
a `b` c,               left (captures lambda)
  all custom operators
??                     left (short-circuits)
..>, <.., ..*>, <*..,  n/a (captures lambda)
  ..**>, <**..
|>, <|, |*>, <*|,      left (captures lambda)
  |**>, <**|
==, !=, <, >,
  <=, >=,
  in, not in,
  is, is not           n/a
not                    unary
and                    left (short-circuits)
or                     left (short-circuits)
x if c else y,         ternary left (short-circuits)
  if c then x else y
->                     right
====================== ==========================

With the rationale for it below :: being so that a :: b .. c raises an error immediately rather than lazily.

[evhub]

Only thing left to do here now is add a warning to catch syntax with a new meaning.

[evhub]

Though it is technically syntactically valid Python, since it's never not a TypeError, we can also allow

5 (x + y)

here if we want.

Actually, this is a bad idea, because it encourages a (x + y), which will fail since that will turn into a function call.

[munael]

Julia has for constants only, IIRC.
So 2x^2 + 4x - 3 looks nice.
But you don't need to parse a x^2 + b x + c, not even mentally.
Even if Julia is in fact not like this, it might be a happy medium worth considering.

[evhub]

@munael The problem with that is that b x is already valid Coconut (it compiles to b(x)). So if we were to add 5 x, but keep b x as b(x), we would still have to parse both, but they would be inconsistent with each other, with one giving you function application and the other giving you multiplication.