.match for numbers ambiguity

[BANOnotIT]

For numbers .match makes additional one/few/many/other/etc variants and that makes it hard to understand how the example below will be handled:

.local $count = {1 :number}
.match $count $count
1   one {{ uno }}
one one {{ ein }}
*   *   {{ rest }}

It's not obvious that 1 can be "1" and "one" at the same time.

[aphillips]

1 and one are not at all the same thing. The key 1 matches the value 1 (and only that value). It's an exact match. The key one matches whatever the one rule in the current locale matches. In English locales, this is the value 1, but in other locales (such as Polish, for example) it matches additional values such as 21, 31, etc. while in others (such as Japanese) it never matches any value. The example is probably not that clear. The pattern should contain something that is related to "exactly one"

See examples in the spec here and here

[BANOnotIT]

Yes, I know that one/few/many/etc are locale dependent. It's just strange that these keywords are not any different from literal value in .match construction at all.

I suppose having syntax highlighting for one as a keyword in and 1 as a literal would help to disambiguate this case

Here's an example where doing syntax highlighting is not that easy:

.local $availability={few :string}
.local $count={10 :number}
.match $availability $count
few one {{ Only one product from several categories available }}
few *   {{ Many of products from several categories available }}
*   *   {{ All products available }}

Here $availability might be an enum of {none, few, all}.

That's what I mean by ambiguity.

[aphillips]

I still don't understand?

From the point of view of the MF processor, all of the keys in a variant are literals. MF very deliberately--and by design--is wholly untyped. The .match selector does not know that 1 or one are anything but literal tokens and it doesn't know what the functional handler will do with them. (In some implementations, it may know which values are "valid" and one of the goals for the future is to add machine-readable function descriptions to allow e.g. static analysis of messages).

The point is: your example is fine, from the point of view that :number's keywords only have special meaning in the context of :number. The ambiguity stems from the fact that both $count and $availability have chosen the same keywords.

In your original comment you noted:

It's not obvious that 1 can be "1" and "one" at the same time.

It is better to think of the value 1 as matching both keys "1" and "one", and, in fact, it matches "1" better than "one" in all locales. But that is specified in the section on number selection in the functions portion of the specification, not in the core of MF.

Does that make sense?

[BANOnotIT]

the value 1 as matching both keys "1" and "one", and, in fact, it matches "1" better than "one" in all locales

.local $a = {1 :number}
.match $a
one {{ one }}
1 {{ ein }}
* {{ uno }}

=> ein

So that's really unexpected. So .match tries to match numbers two times: first as literal and then as locale alias for number?

.local $a = {1 :number}
.match $a $a
one 1 {{ one }}
1 one {{ ein }}
* * {{ uno }}

=> ein

My mental modal from the looks of it suggests that it should match it line by line: first key fully check, second key fully check, otherwise catch-all key. But apperantly it checks first part of the key as literal check and then as class check.

[eemeli]

The ambiguity here is perhaps due to the matching attempting to select the "best" choice among the variants. This is different from how any programming language works, and it ought to be better documented.

[bearfriend]

It's a fair point that is often overlooked by those who spend more time working with MF (1 or 2). Ultimately I agree the solution is probably very big, bold, clear documentation as this confusion persists for people well after they are introduced to MF. However, it's fundamental to the power and utility of the syntax and has been thoroughly planned and implemented, so changing it for this reason alone is not advisable.