Select "Match on variables instead of expressions" for selection-declarations

[eemeli]

This design doc was first proposed back in March, and we should finally start discussing which of its options to choose.

I think the problem originally presented in #736 is real, and not well served by our current syntax. Of the options we've identified in the design document, using variables instead of expressions in .match statements seems like the only one that would simplify rather than complicate our syntax and runtime behaviour, as it removes rather than adds to what we already have.

[aphillips]

Let's not do this until we've agreed on a course to take. We can make this annotation when merging.

[aphillips]

I don't think I agree with this design alternative, since it requires the use of declarations.

[eemeli]

The way I see it, that's the least worst option that we have available. :/

[aphillips]

Okay, but it's a breaking change. The other alternatives have quirks for sure (and I think the mutable/immutable labels might be backwards??), but we need to seek consensus.

[eemeli]

I agree. On this topic, it seems like we've been avoiding expressing any preferences one way or another for a while, so I didn't know of a better way to start seeking that consensus than proposing one solution above the others. The PR is structured in a way that it should be relatively easy for us to change the selection from my initial proposition, should our consensus land elsewhere.

[echeran]

I prefer a different alternative, "Do nothing", that others also share, as pointed out in this comment. We also discussed it in Monday's 2024-08-19 meeting.

The concern with the following set of alternatives is that they propose doubling up the functionality of .match selectors to also behave like a declaration for the input operand to define implicit function option values.

• "Allow both local and input declarative selectors with immutability"
• "Allow mutable input declarative selectors"
• "Allow immutable input declarative selectors"

They are also implicitly creating a new "lexical scope", if you will, that is needed for this implicit binding (declaration).

The concern with the alternative "Match on variables instead of expressions"
is that it is designed for and assumes the scenario that formatting needed for selection and formatting needed for placeholders in the pattern are the same. As Use Case 6 points out, not only can the formatting options differ -- because selection and formatting are distinct operations -- but we might have different formatting functions altogether. The strictness of this option is not appropriate since it's based on an assumption that is not universally true in practice (although I appreciate the good intent behind the idea).

The concerns with "Provide a #-like Feature" are the obvious strong undesirability of positional arguments and the complexity & downgrade to readability that brings. The last time someone discussed positional arguments in earnest here in MFWG was perhaps early 2020...around 4+ years ago, because there was quick unanimous alignment around named arguments.

[echeran]

On the point of formatting for selection != formatting for display, I dug up this "virtual whiteboard" doc from older times of MFWG when we couldn't meet in person (July 2020, to be exact), in which @mihnita and I had a kind of Socratic dialogue where Mihai explained to me through examples why selectors and placeholders are distinct operations and thus cannot be collapsed into a single construct type in the data model.

[aphillips]

In the last call (2024-08-05), which I missed, there was time spent reading the document. In this coming week's call (2024-08-12), please come prepared to discuss the design choice.

---

(chair hat OFF)

I prefer the alternative "Allow immutable input declarative selectors".

My preference is because I think that most messages can use dual-duty input/selectors and that this shorthand will feel natural to users--much more natural than forcing users to use declarations. The syntax is also cleaner, since curly brackets remain delimiters on statements.

Note that the design preferred here probably needs some syntax adjustment. In the doc it shows this:

.input {$count :number}
.match $count
one {{You have {$count} apple}}
* {{You have {$count} apples}}

.local $empty = {$theList :isEmpty}
.match $empty
true {{You bought nothing}}
* {{You bought {$theList}!}}

But these messages could normalize whitespace as:

.input {$count :number}.match $count one {{You have {$count} apple}} * {{You have {$count} apples}}

.local $empty = {$theList :isEmpty}.match $empty true {{You bought nothing}} * {{You bought {$theList}!}}

The selectors and the first key-list are not visually distinguished, which I think is a problem.

[echeran]

During the 2024-08-12 meeting, my views changed most recently by discussion from @lucacasonato and @mihnita about the confusion that users would experience with the option "Allow immutable input declarative selectors" since .match would be doing double duty: it's matching, and it's simultaneously behaving like .input. By the end of that discussion, I felt that the option of "Do Nothing" was best (which means .input and .local already work as intended to handle this scenario, and we can document this better for the user), and that the other proposed options made things worse more than they helped.

Going through the discussion in #736 strengthens that view. I interpret the comments from @catamorphism (link), @bearfriend (link) in this view. Also, @mihnita's point in that thread that selectors and formatters are not always the same for a given data type is very important, and it complicates the arguments in favor of doing something other than "Do Nothing".

I agree with their arguments, which are well stated. FWIW, just to restate & elaborate my way of phrasing it: having one thing called .match serve 2 purposes at the same time (matching + .input-like creation of a new context/lexical scope) is the definition of complexity. We already have .input for creating a new context for a binding name. Let one thing represent one thing only. In the original description of #736, the word "implicit" in "Could we consider making the .match expressions also act as implicit declarations, ..." is to me a red flag of complexity. The design doc's use cases list concision as a goal ("As a user, I want to use the least amount of MF special syntax possible."), but concision != simplicity, and concision at the expense of simplicity is a net negative. So "Do Nothing" is best -- leave well enough alone -- but we can have better documentation for users to help them decide best how to author messages as they intend.

[echeran]

I couldn't leave suggested changes in other parts of the doc via this review, so I created #867, which should be resolved / merged before this PR should be merged.

Also, we should get a group consensus before deciding an alternative and marking as accepted. PTAL at comments, thanks!

[echeran]

I prefer a different alternative, "Do nothing", that others also share, as pointed out in this comment. We also discussed it in Monday's 2024-08-19 meeting.

The concern with the following set of alternatives is that they propose doubling up the functionality of .match selectors to also behave like a declaration for the input operand to define implicit function option values.

• "Allow both local and input declarative selectors with immutability"
• "Allow mutable input declarative selectors"
• "Allow immutable input declarative selectors"

They are also implicitly creating a new "lexical scope", if you will, that is needed for this implicit binding (declaration).

The concern with the alternative "Match on variables instead of expressions"
is that it is designed for and assumes the scenario that formatting needed for selection and formatting needed for placeholders in the pattern are the same. As Use Case 6 points out, not only can the formatting options differ -- because selection and formatting are distinct operations -- but we might have different formatting functions altogether. The strictness of this option is not appropriate since it's based on an assumption that is not universally true in practice (although I appreciate the good intent behind the idea).

The concerns with "Provide a #-like Feature" are the obvious strong undesirability of positional arguments and the complexity & downgrade to readability that brings. The last time someone discussed positional arguments in earnest here in MFWG was perhaps early 2020...around 4+ years ago, because there was quick unanimous alignment around named arguments.

[echeran]

The suggested edit to change the selected alternative is based on my & others' previous comments and meeting discussion. See other comment threads in the PR for specifics.

Suggested change

	The design alternative [Match on variables instead of expressions](#match-on-variables-instead-of-expressions)
	The design alternative [Do nothing](#do-nothing)

[mihnita]

There is also PR #867

I suggested an option there:
#867 (comment)

But we discuss the same thing in so many places that I don't know where to comment anymore...
Let me know if you want me to copy it here.

[echeran]

@mihnita I created #867 to create a quick update to the design doc to reflect the discussion that came up in Monday's 2024-08-19 meeting, as @aphillips's suggested then, and because I couldn't make them as suggested changes in this PR since it's outside the bounds of Github's diff view. I think a separate PR is the way to do it.

(Btw, regarding the idea itself from your comment, I agree with @bearfriend's comment in response. I have more explanation to offer to that position. I can share that with you in a 1:1 chat in case that would affect whether you want to pursue a small PR that adds the option to the design doc so that it gets equal consideration.)

[macchiati]

That discussion is not very clear. Can you boil it down to a reasonable use case where the selection should differ from the formatting semantics (eg disregarding different number systems).

[gibson042]

Isn't that covered by the added example?

.match {$person :gender}
male {{Bienvenido {$person :personName}}}
female {{Bienvenida {$person :personName}}}
other {{Le damos la bienvenida {$person :personName}}}

One can also imagine similar patterns for non-complex inputs such as {$time :partOfDay} (morning/afternoon/evening/night), {$adjective :affect}, or really any kind of "binning" classification into finite categories for distinct treatment that still needs the original value.

[eemeli]

I find the "Do Nothing" alternative problematic because it does not signal anything wrong with a message like

.match {$count :integer}
one {{You have {$count} whole apple.}}
* {{You have {$count} whole apples.}}

If that message is formatted with { count: 1.2 }, the result is "You have 1.2 whole apple." which is clearly not what was intended by its author.

This problem is the main reason that I filed #736 originally, and which I think we need some solution for. As we've discussed on many occasions, MF2 will always be an auxiliary language to its users, and we should not expect users to always remember its details. Therefore, I think it's important that we find some way for the above message to be considered invalid, so that this mistake is caught as early as possible, or we add a side effect to .match so that the desired behaviour is realised.

My own first preference is the alternative proposed in this PR, but I've also filed #860 to provide a next-best choice that retains our current syntax, but signals an error in this particular case, where a selector variable is used in a placeholder.

[macchiati]

Thinking about this some more. My proposal is:

• in a match statement, options effectively mutate variables (see below)
• it is illegal for a variable to occur twice in a match statement.

This keeps most message more concise, producing the expected results: eg without the problems that occur above with input of count : 1.2

Example1.

.match {$count :integer}
one {{You have {$count} whole apple.}}
* {{You have {$count} whole apples.}}

is precisely equivalent to:

.local $count2 {$count :integer}
.match {$count2}
one {{You have {$count2} whole apple.}}
* {{You have {$count2} whole apples.}}

Example 2.
And the following is illegal.

.match {$count <anything>}{$count <anything>}

The message author is required to rewrite it explicitly, eg to:

.local $count3 {$count}
.match {$count <anything1>}{$count3 <anything2>}

I really don't think this is a burden, since the number of times the same variable is used twice in a match (or the older Select) is vanishingly small. Since it is an error — and the advice to fix is easy — that will prevent misbehavior.

[aphillips]

@macchiati

I really don't think this is a burden, since the number of times the same variable is used twice in a match (or the older Select) is vanishingly small.

This is true of numbers. Dates offer an alternative... or person names in which one might want multiple selection from a complex value.

Note: I'm not arguing against the proposal.

[sffc]

A few thoughts on this:

In my experience, this is one of the key problems with MF1 patterns. I filed a bug years ago about how MF1 allowed plural selection to operate on something other than the formatted number. I've reported similar issues in ECMA-402 (tc39/ecma402#397).

Therefore, I think MF2 should absolutely make it easier to do the normally-correct thing (select and format with the same function) than the normally-wrong thing (select and format with different functions). I worry that "do nothing" does not satisfy this.

I find the implicit local scopes confusing. I think it's not an insurmountable problem, but I prefer a simpler solution with slightly more verbosity over one that trades less typing for more complexity and edge cases.

Without taking an opinion on which option to choose, I'll just note that I found .match {$input :function} $local = {$input :function} ("Allow both local and input declarative selectors") to be confusing to read.

An option I don't see listed anywhere that might work would be to say that expressions in a match statement are equivalent to hoisted input declarations. No local scope is introduced. In other words,

.match {$emailCount :integer}

is equivalent to

.input {$emailCount :integer}
.match $emailCount

[macchiati]

That would work for items that don't result from a previous .input or .local, but would force extra lines and a change in variable name for those that do already. That's why I suggested the hybrid approach.

[sffc]

That would work for items that don't result from a previous .input or .local, but would force extra lines and a change in variable name for those that do already. That's why I suggested the hybrid approach.

The "hydrid" approach, which I understand to be similar to the "Allow immutable input declarative selectors" approach, seems workable, but it introduces the implicit local scope, and I find the implicit local scopes somewhat confusing. My suggestion avoids the local scope and works for the majority of cases. I would rather avoid the complexity of local scopes for the sake of brevity, when the alternative is just an extra line of code that is more readable anyway.

[aphillips]

@macchiati and @sffc

Please note that I am about to ballot this issue (there will also be a discussion thread for the ballot, as is customary in this group). I am currently waiting on merging Mark's hybrid approach before launching that.

If there are other options that the group should consider, please file a PR against the design doc, using #870 as a model!

In this case, I'm not sure that what you're suggesting, Shane, is actually different from immutable declaration-selectors, except by how the selector is described. A .match statement has no "scope": nothing can ever appear after it. It is the container of all the patterns when a message contains more than one pattern. The only difference in your example would be that you omit the syntactic sugar of the {/} around the variable name. Actual annotation would be an immutability violation here:

.input {$emailCount :integer}
.match {$emailCount}
* {{{$emailCount} cannot be annotated in the .match because of the .input}}