Reference Resolver Prototype

[stasm]

Here's a prototype of the reference resolver I've been working on. It's based on the architecture of Bundle/Message from projectfluent/fluent.js#365. It uses TypeScript to verify type soundness and the encapsulation of this approach. Right now, only very simple expressions are supported, VariableExpression and SelectExpressions with simple selectors.

[stasm]

@Pike, I'd like to share some progress on the reference resolver, and ask you for early feedback on the code.

The core abstraction here is the Scope, which is kind of like a visitor for different AST nodes. Scope is created every time format() is called, and contains all the data stored by the bundle required for resolving, plus the variables, and errors.

All three existing implementations of the resolver employ a concept of a FluentType, which holds the raw value and offers a toString API. FluentNone is a special kind of a FluentType; it means null by may hold a fallback value. In this prototype I separated two concepts:

• The Value interface wraps raw values and formats them.
• The Result interface handles successes and failures. (It's very similar to the Result class used in the reference parser).

I feel like this division has worked well for the clarity of the code, but I'm interested in your opinion. Thanks, and please let me know if you have any questions.

[Pike]

I don't have the big picture here. What do we want to achieve for our existing implementations, and what for future implementations?

How do we impact interpreting resolvers like fluent.js, or pre-evaluating ones like python, or compiling ones that we have in other parts?

[stasm]

Good questions, thanks. The purpose of this reference implementation is to be able to build a suite of tests and fixtures and verify that the expectations encoded in them are reasonable and possible. I don't think this implementation should dictate the design for other implementations out there. I'd like to start with the test suite defining the conformance criteria for the implementations.

I think the important question right now is what would we like to expect from the errors returned from the resolver. What kind of information is useful?

I added a simple error class in 5b22e6e and a few sample tests in 21a82b7. We'll likely want to have better errors and better tests, but this is still just a draft.

One thing that I notice right now is that it's not easy to decorate the error with the id of the message in which the error was reported, if that message is referenced from the "entry" message with a MessageReference. Is this information we'd like to provide in our errors? Or is it enough to know that the error was reported during the formatting of a given message/attribute value?

Do you have other things on the wishlist for errors? :)

[stasm]

I've reached a point where this PR can serve as a good base for implementing the actual reference resolver and its test suite. I'll base the initial code on the runtime resolver from @fluent/bundle, and I'll file issues to discuss the behaviors which we'd like to codify in the specification.

[stasm]

The code here was based on the second iteration of the FluentBundle API. In the end, we went with the third iteration. #278 tracks my newest attempt at formalizing the formatting spec.