Add hybrid option to selection-declaration.md

[macchiati]

No description provided.

[aphillips]

Minor tweaks

[aphillips]

In the 2024-08-26 call we agreed to fast-track this item. I need one additional approval to merge.

[aphillips]

I think this might be titled incorrectly?

When we say "immutable" in the other options, we mean that the nothing can be annotated twice. Anything can be annotated once (in fact, we insist on it).

Suggested change

	### Hybrid approach: Match may mutate, no duplicates
	### Hybrid approach: Allow _immutable_ input-declarative selectors but forbid duplicates

That is, I think you mean that this is an error:

.input {$foo :integer}
.match {$foo :anything_else}
* {{Can't redeclare $foo}}

[macchiati]

I was actually opening it up beyond that, that is

.input {$in :number}
.local $count = {$in :modify add=-1}
.match {$count :integer}
one {{You have {$count} whole apple.}}
* {{You have {$count} whole apples.}}

would be equivalent to:

.input {$in :number}
.local $count = {$in :modify add=-1}
.local $count2 = {$count :integer} // logically inserted
.match {$count2} // logically replaced
one {{You have {$count2} whole apple.}} // logically replaced
* {{You have {$count2} whole apples.}} // logically replaced

(And that's how it could be implemented internally, without internal mutation.)

[aphillips]

Using only functions in the standard set, would this be a valid restatement of that example, or an error?

.input {$in :number}
.local $count = {$in :number signDisplay=always} // affects the formatting
                                                 // but not selection on purpose
.match {$count :integer} // uses :integer for selection, might be a mutability error?
one {{You have {$count} whole apple}}
*   {{You have {$count} whole apples}}

I don't want to bring in the whole resolved value discussion, just the discussion of immutability, but I think we intended this to be an error currently. Mutator functions, such as your :modify, are super-interesting, in that they aren't really formatters or selectors.

Playing devil's advocate:

.input {$in :number}
.local $count = {$in :modify add=-1}
.local $count2 = {$count :integer}      // typed explicitly by the user
.match {$count2}                        // ... and used to select; can I annotate?
one {{You have {$count2} whole apple.}} // does this get implicitly changed?
* {{You have {$count2} whole apples.}}

Also, what about non-consonant selectors:

.input {$now :datetime}
.match {$now :before field=hour value=12} // is it morning? No effect on display.
true {{You still have time to do it before lunch.}}
*    {{It's already {$now :time} on {$now :date}}}

[macchiati]

My proposal is to add mutability in a very limited circumstance, in the match statement. Nothing before or after would change; the previous .local statements and the variant messages couldn't change a defined value.

.input {$count :number}
// do something else with count
.match {$count :integer} // mutates $count
one {{You have {$count} whole apple}}
\*   {{You have {$count} whole apples}}

I realize that this is a change; however, because we forbid $count being used twice in the .match, I believe it prevents any ill-effects, while also avoiding the truly horrible disconnect between formatting and selection.

I don't see any cases where the relaxation of mutability in the match statement will cause problems. I'm of course interested to see if anyone can come up with any.

There is a weaker variant of this proposal:

Weaker Option

Disallow annotations on match selector operands that have a previous .input or .local. Allow them if there are no such .input or .local statements: as equivalent to an input statement

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

Which would be equivalent to:

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

And the following would be an error.

NOTE: I'm trying to keep this example to the minimum. The match would or variant messages would have to be more elaborate to actually need the "something else".

// ERROR
.input {$count :number}
// do something else with count
.match {$count :integer}
one {{You have {$count} whole apple}}
\*   {{You have {$count} whole apples}}

It would have to be rewritten as:

.input {$count :number}
// do something else with count
.local $count2 = {$count :integer}
.match {$count2}
one {{You have {$count2} whole apple}}
\*   {{You have {$count2} whole apples}}

That would keep everything immutable, but require rewrites using an extra statement and change in names, for any selector operand that needs a .local

[eemeli]

This is fine to add, provided that the inline suggestions below are addressed.

[echeran]

Ditto what @eemeli said -- it looks fine to add, but would like to see the suggested change re: cons addressed.

[aphillips]

I am merging this without changing the title of the proposed option, the better to get the ballot out the door. The conversation @macchiati and I are having above remains interesting to any future technical discussion.

[macchiati]

sounds good

[mihnita]

I know it is already submitted, and we are balloting on it.
But this is risky.

Think of a parameter of type Person, with first / last name, DOB, gender, etc.

.match {$host :gender}
female {You got an invitation from {$host} to her party.}
...

One would really expect something like "... from Maria to her ..."
But because the .match "binds" the parameter with :gender now we get "... from female to her ..."
Can be solved with a local declaration.
But surprising.

So we fix the plural (:number) surprise (select on something and render something else), and we replace it with a different surprise.

[aphillips]

(as individual)

Presumably :gender as a selector is not a formatting function. The default formatting function for $host of type "person" would be implementation defined and presumably not be the :gender selector, despite the annotation. :number or :integer are interesting because they are both selectors and formatters. I can imagine other values behaving like that as well (function defaulting is currently implementation defined)

Compound objects, such as person names or measurements, probably are complicated because of the reasonable desire to do query-style selection (e.g. the plural category of a currency value's number or, conversely, select based on the currency value's currencyCode).

We haven't fully baked "resolved value" yet and this is part of that discussion.

One last thought: is this really that different from some of the other options being balloted? This consideration would go in the pro/con buckets for each.

---

(chair hat ON)

Note that we are balloting selection's relationship to declarations, but the voting is only advisory to a technical conversation. Also, you are encouraged to vote against solutions you don't like and to discuss them on the discussion thread.