Define function composition for :number and :integer values

[eemeli]

A continuation for #798 and #814, defining the composition behaviour for numerical values.

[aphillips]

"can" reads like "MAY", but the other suggested text reads like these "MUST" exist (that is, must be permitted). Perhaps:

Suggested change

	it can include option values.
	it includes any _option_ values of the _expression_.

[eemeli]

See the thread above; the language currently covers numerical types that are not resolved values. With that context, changing this to "it includes" seems a bit wrong?

[aphillips]

We are defining :number and :integer here. Is "such as" needed?

[eemeli]

The "such as" is making sure that the resolved value type is included in the "an implementation-defined type" set of possibilities.

[aphillips]

Presumably it would be that, otherwise the result would be bad operand?

---

Why does the operand need to be of the implementation-defined variety? Aren't option values also applicable to, for example, accepted literal values?

{-1.234 :number maximumFractionDigits=2 signDisplay=always}

Why wouldn't the options "stick to" the value?

Are you trying to say that the resolved value input to the function might be influenced by ("include") the options previously applied? Should we be more direct?

Suggested change

	such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_,
	The _resolved value_ of the _operand_ of an _expression_ includes any of the
	above _options_ applied to the value.

[eemeli]

I'm trying to follow our practice of not defining exactly what a "number" type is, while allowing for some implementation-defined number types, such as the resolved value coming from a :number annotation, to contain options within the value of the operand.

So this is covering each of the following use cases:

1. {$x :number}
   where in a JS context that could be formatted with { x: BigInt(42) }, i.e. using a language-specific numerical type.

2. {$y :number style=currency}
   where in a JS context that could be formatted with
   { y: Object.assign(new Number(42), { options: { currency: 'EUR' } }) },
   i.e. an object that carries both a numerical value and a bag of options.

3. .local $z = {42 :number notation=compact} {{{$z :number compactDisplay=long}}}
   so that in the placeholder the options of the operand $z can be combined with the expression options.

[aphillips]

Right. We're on the same page technically. I'm bikeshedding the language.

I think the challenge for me is that "implementation-defined type" appears to exclude some values (such as literal representation). It's not clear to me if we require the implementation to resolve it to an implementation-defined type. For example, we say:

The operand of a number function is either an implementation-defined type or a literal whose contents match the number-literal production in the ABNF. All other values produce a Bad Operand error.

... but we don't say that the literal becomes one of the implementation-defined types (although it might).

[eemeli]

The thing is, though, that a literal representation of a number cannot include option values within the operand. The annotation of a literally represented number can absolutely have options, but its operand cannot.

[aphillips]

What about transitivity?

.local $a = {42 :number signDisplay=always}
.local $b = {$a :number minimumFractionDigits=1}
{{{$b}'s operand is an annotated literal??}}

[eemeli]

In that example, when resolving the expression defining the value of $b, its operand is a resolved value, an implementation-defined type. The numerical value contained in that implementation-defined type is the number 42, and it includes a bag of resolved options { signDisplay: 'always' }.

When resolving the value of $b or formatting the placeholder {$b}, the only impact that the literal origin of the value should have is that the fallback string that's used for it is |42|, and not e.g. $x.

[aphillips]

ibid.

[aphillips]

"uses" seems wrong to me?

Suggested change

	When an _operand_ or an _option_ value uses a _variable_ annotated,
	When an _operand_ or the value of an _option_ consists of a _variable_ previously annotated,

[eemeli]

This language was suggested by @stasm in #814 (comment), and is currently the same across the three PRs. Would it be ok to not nitpick on this now, and iterate on the exact language once these changes have first landed?

[catamorphism]

Would it be more precise to say that the getValue() method of its resolved value returns an implementation-defined numeric value? (Assuming the definition of resolved values in #728.)

[eemeli]

Yes.