Clarify the formatting spec wrt. inspecting formattable values

[stasm]

Originally posted by @stasm in #511 (comment)

I'm not sure if the spec is currently clear enough about the requirement to allow functions to inspect the raw value and the formatting options of their arguments. Specifically, while a function may eagerly format its operand to a string, it should (must?) also return the raw underlying value and the formatting options used for formatting, in case another function wants to extend them or use them for other logic. Consider:

local $a = {1 :number minIntegerDigits=3} // formats as 001.
local $b = {$a :number minFractionDigits=3} // formats as 001.000
// min integer digits are preserved from the previous call.

input {$item :noun case=accusative count=1}
local $colorMatchingGrammaticalNumberGenderCase = {$color :adjective accord=$item}
// :adjective inspects $item to learn about case=accusative, count=1

[stasm]

Originally posted by @aphillips in #511 (comment)

I think it has to work that way. I don't think "eager" evaluation is necessarily to a string. It is to a "formattable". Otherwise format-to-parts wouldn't work nor would (as you point out) later annotation. Also, selectors wouldn't work:

input {$num :number maxFactionDigits=0}
match {$num}
when one {{ won't get here because {$num} won't be the string 'one' }}
when * {{  :-( }}

What "eager" evaluations might do is copy the value and modify the copy:

input {$startDate :systemTime}
local $endDate = {$startDate :add unit=days increment=6}

[eemeli]

Here's the full set of methods/accessors that the proposed JS implementation uses:

• get options
• get value
• format to string
• format to parts
• select keys

As far as I can tell, that's the minimal set covering all the possibilities.

If it's not clear that the spec effectively leads to that sort of an implementation, that might indeed be good to clarify in its text.

[catamorphism]

Originally posted by @stasm in #511 (comment)

I'm not sure if the spec is currently clear enough about the requirement to allow functions to inspect the raw value and the formatting options of their arguments. Specifically, while a function may eagerly format its operand to a string, it should (must?) also return the raw underlying value and the formatting options used for formatting, in case another function wants to extend them or use them for other logic. Consider:

Is it that the function has to return that, or that the formatter implementation has to bind the name $a to a value such that the raw value and options can be inspected? Requiring implementors of custom functions to write their functions this way seems challenging.

By the way, this seems like a case for making the spec be less abstract about what a "resolved value" is allowed to be.

[eemeli]

Specifically, while a function may eagerly format its operand to a string, it should (must?) also return the raw underlying value and the formatting options used for formatting, in case another function wants to extend them or use them for other logic. Consider:

local $a = {1 :number minIntegerDigits=3} // formats as 001.
local $b = {$a :number minFractionDigits=3} // formats as 001.000
// min integer digits are preserved from the previous call.

One thing to note here is that the "raw underlying value" should in this case be the number 1 for both $a and $b, rather than the source string '1'. So perhaps we should not use the term "raw" here.

[aphillips]

I think this needs concrete suggestions in order to be actionable. Can we produce a PR with proposed changes?

[catamorphism]

I'm working on a proposal for this.

[aphillips]

Moving to LDML46 to match Tim's proposal.

[catamorphism]

Does #728 address this fully? (I think it does.)

[aphillips]

Hi @stasm. I know you've been busy. Are you satisfied with this issue's resolution? Thanks.