Add errors for invalid expressions including type mismatch

[aphillips]

Around here in #621 we identified that we do not have a Resolution Error for internal failures in expression resolution, including for type mismatch. This issue tracks creating such an error and point it from the spec where needed.

[catamorphism]

I'm assuming the following, from the linked-to comment, is the example you have in mind:

.local $x = {horse :number}

Wouldn't this be considered a Formatting Error?

Formatting Errors occur during the formatting of a resolved value, for example when encountering a value with an unsupported type or an internally inconsistent set of options.

(From https://github.com/unicode-org/message-format-wg/blob/main/spec/errors.md#formatting-errors )

[aphillips]

That's what I thought. But is it a formatting error if it isn't yet being used for formatting (or selection, for that matter)?

[catamorphism]

I think so. In an eager implementation, the :number selector has to be called before $x can be bound to a value. Hence this would be a formatting error, even if $x is never used.

A lazy implementation would simply bind $x to a thunk without calling the implementation of :number. However, as a general rule, lazy implementations are free to omit errors that would be present if the same message was evaluated eagerly.

[eemeli]

This is not a formatting or a selection error, this is an error in determining the numerical value of a horse. If we could determine that value, then it could be used for selection, or formatting, but we can't. As we currently call this process "Function Resolution", we call the error a "Resolution Error".

If the sense is that "resolution" is not an appropriate word for this error, then it likely isn't appropriate for the process either, and we should discuss it's name as well, which is best done by considering some alternative proposals for it.

[catamorphism]

I thought that the implementation of number was responsible for validating its input (and emitting an error if it's invalid). That's what the language under "function resolution" suggests -- step 4 is to "Call the function implementation with the following arguments.... If the expression includes an operand, its resolved value." This suggests to me that the function implementation will be called on any resolved value, and if the input is not what the function expects, the code implementing the function is what signals the error.

Is that wrong?

[aphillips]

@catamorphism It's not wrong. On some level, we're debating "what to call that error". The current set of resolution errors covers a bunch of cases pertaining to the expression (which the implementation can mostly catch without calling the function), but not what happens once the function is called.

Presumably, implementations will provide to functions that plug in (or which they build in) a means to communicate more than just "it threw an error" or "it didn't work", such as a typed exception they can throw.

[catamorphism]

@catamorphism It's not wrong. On some level, we're debating "what to call that error". The current set of resolution errors covers a bunch of cases pertaining to the expression (which the implementation can mostly catch without calling the function), but not what happens once the function is called.

Presumably, implementations will provide to functions that plug in (or which they build in) a means to communicate more than just "it threw an error" or "it didn't work", such as a typed exception they can throw.

That makes sense. I was wondering if we had decided to add typechecking as part of the message formatter implementation itself (prior to calling the function). It sounds like no.

But I'm still not sure why this is a resolution error. errors.md says: "Resolution Errors occur when the runtime value of a part of a message cannot be determined." I don't know what "runtime value" means here, but if I interpret that broadly, then all formatting errors and selection errors are also resolution errors. If I instead interpret it as a synonym for "resolved value", then a "type mismatch" is not a resolution error, since (going back to the example) horse has a resolved value.

If on the other hand the "type mismatch" error is another kind of error under "formatting errors" (with "formatting errors" including a "type mismatch error" and separate "miscellaneous formatting error"), then that makes sense to me.

[aphillips]

I'm going to Agenda+ this item.

I had basically the same cognitive dissonance here--in writing the :datetime or :number spec, the errors occur inside the function and while I'm thinking about selection or formatting operations.

My cognitive dissonance extends to (as I've said elsewhere) the fact that selectors are definitely not "calling the function" or returning some sort of value. They do require everything else in function resolution to (so that the operand and options are prepared for MatchSelectorValues to be called)

@eemeli rightly points out that expressions exist in other places--notably in declarations--and they get "resolved" first. And eager or lazy, you can't actually call the formatting or selector function until you resolve the operand and the options. This can involve walking back up the stack to find the concrete value (particularly in a lazy eval situation). To wit:

.local $b = {$a}
.local $c = {$b}
.local $d = {$c}
{{Printing {$d} means finding out what the value of {$a} is (eventually)}}

We could call the "internal" errors something other than a "resolution error", in terms of grouping in errors.md and we almost certainly need to clean up the text in errors.md as a result.

Ultimately, I think we need to discuss error management in a high-bandwidth (i.e. phone call) space.