e^{|x|}
f_{i(x)}
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.
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?
- You can add an arbitrary number of trailing `[..]` blocks and they are just trailing arguments. So 2 & 3 are really the same.
- 3 & 4 are different because argument lists may _never_ have a space before them in Typst. you can also not write `calc.min (1, 2)`
The reason why the space may not be added is that you can write
#for x in range(5) [
Value is #x
]
1/2(x + y)
1/x(x + y)
1/2^x(x + y)
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.
It may be related to the fact that "mixed numbers" were never part of my curriculum (Wikipedia¹ says they are more common in non-metric regions). Or it may be just me. In any case, I find this notation ambiguous, so I would not expect a compiler to resolve it correctly.
Edit: also, I would rather write (x + y)/2 if I wanted half the sum, that seems much more logical to me than moving non-integer factors around.
https://github.com/typst/typst/pull/7137
from what I can tell. The commits look two days old so work looks on going.
I do not understand the current set of preferences laid out in:
https://github.com/typst/typst/pull/7072#issuecomment-338580...
I do not understand 8, 9 'my preference' column and why they would make the similar syntax render differently.
The preferences there were honestly rather ad-hoc w.r.t to the pull request and the approach the pull request took. And (as the author laid out), the PR was a rather ad-hoc solution for a problem we discovered literally one night before Typst 0.14 was supposed to be released.
The design thoughts there were a bit half-baked, which is why we've closed the PR and reverted the original change, to get more time to properly reconsider things.
The math syntax has seen little change since Typst's initial release (except for the infamous precedence change in 0.3 that triggered all this) and just has some quirks that haven't been properly ironed out yet. However, it will remain a focus now and we want to give it a proper cleanup.
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.
It is just plain simpler than the original TeX/LaTeX notation.
e^ x-1 <- "e with x minus one as superscript"
e^x - 1 <- "e with x as superscript minus one. Same as e^x-1"
f_ i(x) <- "f with i of x as subscript"
f_i (x) <- "f with i as subscript of x. Same as f_i(x)"
f_i .$ (x)
a / b.*(1 - x)
sum_ X_ i.,j
[1]: https://pandoc.org/
And since probably many people are very familiar with it, I would have liked for them to just keep that part.
I feel like this is a lesson people keep learning over and over across programming languages: don't let your syntax try to infer the intended meaning of what was typed, just do something simple and predictable.
So (b) seems like the only sane choice, but having the grouping operation being e^(abs(x)) is also crazy. You need something like TeX's e^{abs(x)}.
Personally I think the "best" workaround for this is to decouple the text representation and the representation the editing happens in. Allow people to type e^abs(x) and then the editor translates that into e^{abs(x)} while letting you edit it as an exponential, but if you're working on the underlying text file then you have to write e^{abs(x)}. For that matters, you can just have the editor represent it as a literal superscript.
(My hunch is that this is generally much-needed across languages: let the editor do some of the parsing work. I think there's much to be gained by separating the two, because you can keep the parser of the actual language simple while still getting all your editing-efficiency improvements out of the editor).
I had a similar dilemma before I released 1.0.0 last spring, and decided against special cases like these. In Mathup binary operators (^, _, and /) always operate on exactly one group after the operator, regardless of (what I believe is) the author’s intention. So 1/2(x, y) is the same as 1/x(i, j) is the same as 1/f(x, y). I only have a couple of exceptions regarding spacing on trig functions, and (what I believe is) the differential operator. But if you want an implicit group to e.g. under a fraction, in a superscript, you must either denote that with spaces e^ x-1, or with parens e(x-1) [I courteously drop the parens from the output in these troubled expressions].
another case for using proper notation π with some autosubstitution rules so that you can resolve the ambiguity immediately while typing (if pi is converted into π you backspace and let it stay pi as a function)
But #functions also seems like a good option for readability
exp(e, abs(x))
Latex equation compatibility seems like a blocker for many. Maybe they should have a library that allows one to drop in latex formulas?
TimorousBestie•5d ago