That doesn't really make sense as a Classical Chinese sentence. 曼德博术使以广纵二数也。 is a bit closer to how you might see it in a non-mathematical text.

術means something closer to "method," "procedure," or "way to do something." It's not a function or something that takes arguments in the modern sense.

This programming language is following the style of ancient Chinese mathematical treatises very closely, which are all of the form

X术曰：……

FYI I studied ancient Chinese history and some classical Chinese. I believe you have a blinkered view of valid grammatical constructions, perhaps due to focus on later period texts. IMHO in gross simplification, the earlier you go the less grammatical fluff is required, and the more is open to interpretation. I am not an expert but compare, say, a Three Kingdoms period text to a Tang text. In my impression your construction is far more explicit and latter-day. Nobody wrote like that early on, especially for content tending toward the philosophical.

I'm writing in a style somewhat following a Warring States to Han Dynasty text (the 九章算术). The problem isn't the concision per se, it's that that's just not what 术 means here; it's not something that takes arguments. I'm being slightly verbose but I can't think of a construction that doesn't involve 以 or 数 (or synonyms thereof). It's true you don't need both.

Now there is a way to make your construction work with a wider context, for example in one where you've established 术 as the notion of a function.

Your general impression is correct that earlier texts tend to get more concise and that Classical Chinese is quite grammatically flexible. But there's still limits.

Moreover ancient mathematical texts tended to be far more explicit and written in a far more direct style. Ending particles such as 也 are actually fairly rare in such texts.

Could be far fewer keystrokes with character prediction. First would be 7 instead of 19, ignoring Enter/arrow/mouse clicks.

A couple notes on keystrokes:

1. Ignoring prediction, you need more than three keystrokes to type 事 ("shi"). You type the s, the h, and the i, and then you select the character you want from a menu of suggestions. If you're typing a rarer character (which 事 is not), you'll need additional keystrokes to page through the suggestions.

2. If you're serious about minimizing keystrokes, you'd use double pinyin input, not pinyin input. Two keys per syllable; probably three per character since a lot of repetition means the characters you want are likely to be top suggestions.

> and then you select the character you want from a menu of suggestions

Notably, anything reasonable that lets the user just keep mashing the keys is gonna be faster than selecting stuff on the screen, assuming the user is experienced with typing. Because seeing a wrong predicted character, then looking at the menu, then—crucially—locating the necessary character and then selecting it will be way slower than punching keys in without interaction. Making choices and, separately, selecting stuff on the screen are both slower than just jerking the fingers from muscle memory. More so if the user is a touch-typist.

If you know that your ‘事’ is something like ‘shi down-down-enter’, it would still be faster than the same thing with unfamiliar choices in the menu—or if the prediction and the choices change between invocations. Though this handicap would diminish after the choices settle on the user's typical most-used characters and the user in turn gets used to them.

This is not strictly true. On modern IMEs, usually the first character is enough if the compound you are typing is predictable.

Examples: dnxb would input 东南西北.

Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization.

> dnxb would input 东南西北.

Yes, that's why I started out by saying "ignoring prediction".

However, it's perfectly fair to note that you can and should enter phrases all at once as opposed to one character at a time, which would reduce the double pinyin input from 3 keystrokes per character to two per character plus one per "input unit".

> Then there is learning. While on OSX's pinyin input 曼德波 requires mandebo the first time, it then becomes the first result for all subsequent inputs. We may assume that most multi-character function names would quickly benefit from similar prioritization.

Yes, I noted this specifically:

>> a lot of repetition means the characters you want are likely to be top suggestions

Apologies I mentally switched off when you mentioned 'double pinyin'. Maybe I use that anyway.

You could also treat 也 as ; in some other language syntaxes (eg. ruby), so newline could be semi-synonymous, so the use of 也 becomes superfluous unless you are writing one liners. So that's down further to 6 characters. Even if 'f mandelbrot(width,height' was used in an autocompletion IDE, the traditional syntax weighs in at 24 characters or 4x.

In idiomatic Wenyanwen, yeah, but you need to somehow delimit the token boundaries between 寬 and 高.

For the parsing problem, you can just enforce single character variable names.