[DESIGN] dataflow for composability (#515)

[catamorphism]

This proposed design doc addresses an issue titled "inspecting formattable values", which is really about dataflow through the formatter and structuring it to make function calls compose with each other.

Another PR, #646 , shows how the spec would change if this design doc was accepted. I made changes to the design doc after making the changes to the formatting spec in #646, and didn't have time to update the formatting spec accordingly (yet), so while #646 uses some different terms, it should still serve to give a sense of what the spec would look like if this design doc was accepted.

This is not a finished design doc by any means, but I'm hoping to get a thumbs-down or thumbs-up on the idea before I polish it any further.

[eemeli]

I am not comfortable attempting to review this design doc and the accompanying spec changes during this week. The changes they propose are extensive, but at the same time it's not clear to me if they actually change any externally observable behaviour.

As in #515, the doc starts from a premise that

Custom formatting functions should be able to inspect the raw value and formatting options of their arguments.

but does not discuss why access specifically the a "raw" value (and options?) is required or beneficial, as opposed to a value and options. I am concerned that such a starting point limits the expressibility of e.g. messages such as:

.input {$names :list}
.local $head = {$names :slice start=0 end=2}
.local $tail = {$names :slice start=2}
.match {$head :count} {$tail :count}
0   *   {{No-one liked this}}
one *   {{{$head} liked this}}
*   0   {{{$head} liked this}}
*   one {{{$head :list type=unit} and {$tail :count} other person liked this}}
*   *   {{{$head :list type=unit} and {$tail :count} other people liked this}}

where a complex input value (a list of names) is used to construct other complex values, on which further operations (determining the item count and adding list formatting options) result in selection and formatting.

It's entirely possible that the above works fine with the proposed text, but this current week does not provide sufficient time for making that determination for this particular case, or for other complex messages.

I'm also a little surprised by the number of new interfaces that are introduced. For the JS implementation, I found it sufficient to have a single MessageValue interface representing what the current spec text refers to as a "resolved value".

[stasm]

@aphillips:

However, I think it's too specific. This would require implementations to write their internals in specific ways (and we'd have to create tests to prove that the implementation had followed the spec).

I actually think this is rather agnostic, which is why it may also seem like it introduces a lot of new interfaces, as @eemeli observed.

---

I gave @catamorphism feedback on an earlier draft of this PR, and I'd like to have more time to review this iteration, but I won't be able to get to it this week.

I'd love to be able to continue discussing this post-LDML 45. Perhaps this is part of the "implementer's feedback" that we're looking for?

---

In the meantime and in the 45 timeframe, would it make sense to review #646 looking for changes which would introduce incompatibilities to the current spec? If all #646 does is clarify concepts without changing the observable formatting behavior, then I think it should be acceptable to continue this work for possible inclusion in the final spec?

[catamorphism]

I'll plan on reading through the formatting spec to look for anything that would make it impossible to adopt this proposal later. (Busy week for me so I'm not sure when, but I'll do my best.)

[mihnita]

I think this document focuses too much (only?) on the idea of the same function merging options or not.

But I don't think that is very interesting, or useful. It only saves some typing. And I don't think that using variations of the same parameter (with different options) are that common.

What is the most interesting is composing functions by "chaining" them. Functions that take one type + options and return a different type (or the same type), with new, or possibly modified options.

That would allow (for example) to do transformations on parameters.

Take a person and return date of birth. Take a date and return days since that date.

Take a string and return a transformed version of it (changing case, or grammatical form). Or return the original string, but with extra info attached as option (for example result of a grammatical analysis).

[catamorphism]

@mihnita That's fair; the document does focus a lot on composing options because that's the problem that comes up first with built-in functions. (Composing number with datetime, or vice versa, isn't too interesting.) There is an example in https://github.com/unicode-org/message-format-wg/pull/753 ("Example B1") of what you're talking about. Since #753 is intended to land before this PR lands, do you think that's enough or would you prefer to see more examples like that?