Typst's Math Mode Problem

Having run into this bug/syntax ambiguity in my writing a lot, I don’t find it’s much of a bother. The typst engine runs fast enough that most of the time I can run a synced preview window, which makes this particular foible easy to catch.

In LaTeX that would be close to option 2:

    e^{|x|}
    f_{i(x)}

Except with {} for grouping, which I think is a good thing, as {} are never rendered, unlike parenthesis.

I haven't used Typst much, so I am a bit wary of typesetting engines that are "too smart": It can be problematic when introducing new notations, which is quite common.

I had my gripes with LaTeX but the backslash in front of every macro was never one of them. I think it helps not only machine parsing but very much my human visual parsing.

BTW one related trap in LaTeX is if a macro without parameters removes the trailing space from the output. The article mentions this in passing but does not say what Typst's solution is. Do Typst functions always require parentheses?

I'm also confused about the following syntax and especially where the function ends:

    table.header([A], [B]) // This one is clear

    table.header()[A] // Makes sense, [A] turns magically into last param

    table.header()[A][B] // Slightly confusing, why would [B] also belong to the function? But OK.

    table.header()[A] [B] // Totally confusing, why is this an error now?

For the last case: If it is a parameter list a space should not matter, if it is not [B] should not be part of the function and treated as unrelated.

I really don't see the problem with the current notation. I find that is very simple and intuitive: function calls bind tightly, use a space to change that.

f_i(x) vs f_i (x)

1/x(a+b) vs 1/x (a+b)

ab vs a b

So simple. Being too "smart" invariably leads to more headaches and confusion than just having a simple, consistent rule.

I find https://github.com/typst/typst/pull/7072#issuecomment-338580... more enlightening about what's going on. Specifically the difference between these three:

   1/2(x + y)
   1/x(x + y)
   1/2^x(x + y)

With a programming language background, that's just odd to reconcile. If 1/2 is treated as a rational integer literal, it's possible to explain the difference between the first two. (And apparently this difference is wildly expected, uncommon as fractions as literals are in programming languages.) But then the last one should turn into (½)ˣ(x+y) because the exponentiation should not slip inside the literal. (I expect the different outcome in the comment is not the result of an algebraic simplification in his case. I really wish they had used 2/3 as the fraction to clarify this.)

It seems that TeX users struggled with this at one point, too. That's why LaTeX users generally write $\frac{a}{b}$ instead of $a \over x$. Copious use of braces not rendered in the output certainly avoids precedence issues.