A basket of syntax ideas

[eemeli]

I've been playing around a bit with preamble+variant syntax ideas, and would appreciate some feedback on this (in particular from @mihnita, @stasm, @gibson042 and @markusicu) before taking it further. This is not intended to be yet another competing syntax proposal, but a basket of related potential changes to the starting-point syntax. If the responses to these ideas are positive, I'd be happy to craft a corresponding set of PRs to spec/syntax.md.

With empty lines separating messages of increasing complexity:

One {$color} shirt

{? $count}
{= 1} One {$color} shirt
{= *} {$count} {$color} shirts

{! $color = {$item :color} }
{? $count $color}
{= 1 *} One {$color} shirt
{= * *} {$count} {$color} shirts

{!
  $count = {$orderSize :number maximumFractionDigits=0}
  $color = {$item.style.color}
}
{? $count:plural $color}
{= 1 *} One {$color} shirt
{= * *} {$count} {$color} shirts

The changes here compared to the starting-point syntax are:

1. Start in text, rather than code, dropping the Plain production (see #256).
2. Split the preamble into separate declarations {! ... } and selectors {? ... } (the latter as originally suggested by @markusicu). For clarity, the selectors might not be allowed to take options. (see #252)
3. Delimit keys with {= ... }, and Use * instead of _ as the catch-all variant key #274.
4. Do not delimit values, and handle value trimming following one of the options discussed in #275.
5. Make all syntax starts two characters long, as discussed in #269, allowing e.g. {foo} to not be parsed as syntax.

As a core optimisation target I've taken the experience of someone either seeing MF2 for the first time, interacting with it rarely, or as one of a number of different message/template formatting syntaxes. The syntax pairing {? ... } / {= ... } is a key aspect of this idea, and explicitly intended to get the reader to parse the most complex part of our syntax as something like "question/answers". Really, much of the rest flows from that change, of wanting establish a correspondance but not an equality between those syntaxes. The arguments that @gibson042 makes in #269 have been significant for me here.

The separate {! ... } declarations part is effectively a return to the earlier syntax structures proposed by @mihnita, @stasm and myself to the CLDR/ICU TCs.

As argued in #275, I do not think we should be delimiting variant values. Recognising that not everyone shares this view, variants of the above proposal that do {delimit} values could look like this, with and without key delimiters:

{!
  $count = {$orderSize :number maximumFractionDigits=0}
  $color = {$item.style.color}
}
{? $count:plural $color}
{= 1 *} {One {$color} shirt}
{= * *} {{$count} {$color} shirts}

{!
  $count = {$orderSize :number maximumFractionDigits=0}
  $color = {$item.style.color}
}
{? $count:plural $color}
= 1 * {One {$color} shirt}
= * * {{$count} {$color} shirts}

Both of these choices would require dropping change 5, as the value-end indicator } would always need to be escaped. The first of these is structurally rather close to the syntax proposed in #266; the relevant differences are:

1. Including {! ... } as delimiters for the declarations.
2. Using {? $foo $bar} rather than [{$foo} {$bar}] to delimit selectors.
3. Delimiting keys with {= ... } rather than [ ... ].
4. Not including a {#count} variable. This addition to the syntax should probably be considered as a separate issue altogether.

---

PS. When playing around with syntax ideas, VS Code autodetected my scratch document as powershell. That's the code highlighter mode used here.

[gibson042]

The syntax pairing {? ... } / {= ... } is a key aspect of this idea, and explicitly intended to get the reader to parse the most complex part of our syntax as something like "question/answers".

I really like this, and the examples theirselves are approachable from this perspective without much more explanation—I think someone could go from inexperienced to comfortable very quickly and easily. And assuming the whitespace trimming of #275 is nailed down (specifically what counts as trimmable and the stability of that definition over time as Unicode data itself changes), following the keys with unescaped text is a good fit.

I would still advocate carrying the "make all syntax starts two characters long" reasoning into placeholders as well (e.g., {{$color}} rather than {$color}), but that seems independent of the main topic here.

Thanks!

[markusicu]

A lot of this looks good, assuming we start in text mode. Starting in code mode gives more freedom for the code syntax, allowing that to be more elegant.

The whitespace trimming is easy in common cases but hard to get right in edge cases, thus I have been arguing for starting in code mode and delimiting user-text patterns.

The example also suggests separating the formatting from the selector definition. That is problematic, especially for plurals. Formatting and selection are tied at the hip, and should be expressed visually together to make that clear. That means that each selector needs to be able to take options, and thus each selector needs to be individually delimited.

[mihnita]

I think it can work.

But I am 100% against {? $count}

Selectors need a function (possibly with options), otherwise one can do this:

{? $count}
{= 1} ...
{= one} ...
{= five} ...
{= masculine} ...
{= foggy} ...
{= *} ...

And it is perfectly valid.
But there is no way for a linter to validate, or for a localization tool (or even a human) to add missing cases.
Because there is no type info associated with $count at those levels, only at runtime.

So we should not allow a selector without a function.