Add Resolved Values section to formatting

[eemeli]

This PR is effectively an extended comment on the ongoing discussion in #515 / #645 / #646. It also closes #678.

The intent with the change proposed here is to keep our formatting spec close to its current shape, but more clearly define what "resolved values" are, and via a non-normative example guide the reader towards a mental model of what a "formattable" or "selectable" value might look like.

I think this could be included already in LDML45 as its doesn't actually change anything, but that's of course presuming a lot of consensus.

[macchiati]

I like the direction this is going, but I think we really never want to use the naked 'value' term. There are different kinds of resolved values, and it is important to keep them separate to prevent confusion. The value of {|3| :number minSignificantDigits=4} is not 3, nor is it 3.000.

But high bit, this is a difficult issue, and if we rush it it is not unlikely that the spec for tech preview will be worsened. At this point, I think we would almost be better off having a NOTE explaining that we will be revamping this section to clarify the language in the following ways: ...

On Mon, Mar 18, 2024 at 2:11 PM Tim Chevalier @.***> wrote:

@.**** commented on this pull request.

I know that this is non-normative text, but my conclusion after reading it is that there should be a design doc.

Some of it should be normative: specifically, the question of what functions take and return, which has to be answered (IMO) for the registry spec to make sense. How to describe that takes some thought, as I said in one of the comments. The task is to design a foreign function interface that's abstract enough to be adapted to a range of implementation languages, while concrete enough to make the spec something that can be implemented in a way that affords confidence that an implementation conforms to the spec. That's not easy.

Given the amount of discussion the question of "what is the domain and range of a function?" has generated, and how closely coupled that question is with "resolved values", I think it's worth a design doc. This could be #645 https://github.com/unicode-org/message-format-wg/pull/645 or someone could start afresh.

In spec/formatting.md https://github.com/unicode-org/message-format-wg/pull/728#discussion_r1529229458 :

-> Alternatively, it could be an instance of an ICU4J FormattedNumber, -> or some other locally appropriate value. +> With this approach: +> - An expression could be used as a placeholder if +> calling the formatToString() or formatToX() method of its resolved value +> did not throw an error.

"Throw an error" is not terminology that's used elsewhere in the spec (as far as I can recall), and sounds implementation-language-specific. My intention is not to nitpick about the terminology, but to ask how to structure this exposition in a way that doesn't favor one specific implementation language. For example, in some cases, it might be more appropriate for the MessageValue interface to include isFormattable() and isSelectable() (and so on) as predicates.

In spec/formatting.md https://github.com/unicode-org/message-format-wg/pull/728#discussion_r1529235754 :

+> did not throw an error. +> - An expression could be used as a selector expression if +> calling the selectKeys(keys) method of its resolved value +> did not throw an error. +> - Using a variable reference, the resolved value of an expression +> could be used as an operand or option value if +> calling the getValue() method of its resolved value did not throw an error. +> In this use case, the resolvedOptions() method could also +> provide a set of option values that could be taken into account by the called function. +> +> Extensions of the base MessageValue interface could be provided for different data types, +> such as numbers or strings, +> for which the unknown return types of getValue() and resolvedOptions() +> could be narrowed appropriately. +> An implementation could also allow MessageValue values to be passed in as input variables, +> or automatically wrap each variable as a MessageValue to provide a uniform interface

I think this is missing an explanation of what the value (or resolved value?) of an input variable is. It's implementation-specific, and doesn't necessarily have to be the same as the "resolved value" that can appear in various parts of a message as explained above.

In spec/formatting.md https://github.com/unicode-org/message-format-wg/pull/728#discussion_r1529260841 :

-Expressions are used in declarations, selectors, and patterns. -Markup is only used in patterns. +This specification allows for the same value to be used for: +- formatting in a placeholder, +- selection in a selector expression, +- as the operand of another expression, or +- as the option value of another expression,

I think this language is mixing phases. A "resolved value" is a runtime concept. Syntactically, what can be the operand of another expression is either a literal or a variable reference. At runtime (while formatting, when the values of input variables are known) some process maps a literal or variable reference onto a resolved value.

I have a branch where I tried writing up an operational semantics https://github.com/catamorphism/message-format-wg/blob/opsem/exploration/operational-semantics.md, which would answer the question of "what are the relations that map terms onto values?" (A term being an instance of the data model.) This would be a way of providing a declarative spec, which forces one to answer the question of "what are the values that terms map onto?" I wrote this to try to validate my intuitions for #645 https://github.com/unicode-org/message-format-wg/pull/645 and wasn't intending to submit this as a PR or even share it, so it might not be readable by anyone except me.

At any rate, a different way to organize this text might be to say something like:

"Resolved values appear in

• Literal resolution
• Variable resolution
• Function resolution
• Option resolution"

which would at least be describing a runtime process. Or even something like:

"Resolved values appear in

• Literal resolution (resolution maps a literal onto a value)
• Variable resolution (resolution maps a variable, along with context, onto a value)
• Function resolution (functions map values onto values)
• Option resolution (resolution maps the right-hand side of an option onto a value)"

(Using "right-hand side" instead of "value" in the last bullet point to avoid using "value" with two different meanings in the same sentence.)

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/message-format-wg/pull/728#pullrequestreview-1944122274, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMBC74VQZGIAC6GD35DYY5J7NAVCNFSM6AAAAABEVFFBS6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNBUGEZDEMRXGQ . You are receiving this because your review was requested.Message ID: @.***>

[aphillips]

In to 2024-03-25 call we agreed to work on this in the Tech Preview period.