Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typst's Math Mode Problem

laurmaedje.github.io

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Typst's Math Mode Problem

#21

Post by trueismywork »

ajkjk wrote: post #19

It feels absurd to have this occur in the parser, as if you can somehow account for all the cases via guessing what people I mean. You absolutely must have a grouping operation like {} at least available as a fallback. 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 pre…

I complained about this before and people dismissed me as an old timer. I did doubt myself as well to be honest. Its bittersweet to be correct.

Re: Typst's Math Mode Problem

#22

Post by weinzierl »

laurmaedje wrote: post #13
weinzierl wrote: post #6

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 conf…

While not really related to the math topic, let me answer this: - 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 #…

Seeing it this way it makes sense. Thanks!

Re: Typst's Math Mode Problem

#23

Post by xico »

weinzierl wrote: post #6

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 conf…

Plus you can always `\catcode\∘=0` if you really hate backslashes :-D

Re: Typst's Math Mode Problem

#25

Post by runarberg »

ajkjk wrote: post #19

It feels absurd to have this occur in the parser, as if you can somehow account for all the cases via guessing what people I mean. You absolutely must have a grouping operation like {} at least available as a fallback. 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 pre…

I am the author of a (somewhat) competing parser called mathup[1] which has a similar syntax. I based mine heavily off of AsciiMath which has {: group :} as a fallback grouping operator. I kept it, but if I would have done it over I would have replaced it with { group } and used {: group :} for curly brackets.

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].

1: https://mathup.xyz

Re: Typst's Math Mode Problem

#26

Post by eviks »

>pi(1 + 2) is a function call or just pi multiplied by three.

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

Re: Typst's Math Mode Problem

#29

Post by fwlr »

andrepd wrote: post #8

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.

From quickly messing around in the playground, it seems (in math mode) Typst treats multiple spaces identical to single spaces. A simple, consistent, flexible, and probably-not-majorly-breaking-old-documents rule would be “anything with no spaces has higher precedence / tighter binding than anything with one space, anything with one space has higher precedence / tighter binding than anything with two spaces”, etc, and then - only within each spaces category - you apply one of the precedence rulesets described in the article. Any confusion or surprise can be solved intuitively and without thought by mashing spacebar.

Re: Typst's Math Mode Problem

#30

Post by jeremyscanvic »

__mharrison__ wrote: post #28

I'm not a big math mode user (but I use typst a lot). Latex equation compatibility seems like a blocker for many. Maybe they should have a library that allows one to drop in latex formulas?

Seems to be what those guys are up to: https://typst.app/universe/package/mitex/
Post reply on HN