During the writing of the tests for a fully formed data structure + text template, it’s come to my attention that writing those templates well is exceedingly hard.

The test right now uses the format string:

{l:/current/context/+adventurer/@name} {l:/current/context/+adventurer/possessions/@transportation > @v-travel}
{c:/current/context/+goal/@distance} kilometers to {l:/current/context/+goal/+location/@name}
to buy {l:/current/context/+goal/@item > @name,@count=/current/context/+goal/@count}
for {l:/current/context/+adventurer/@gender > @pronoun,@count=/current/context/+adventurer/@count;r}.

Which is expected to turn into:

Chris walked 16 kilometers to The Generic Store to buy 1,040 glass marbles for himself.

This is non-trivial to write. First off, the lookup names require cross referencing to find what you’re looking for. I find myself flipping back to the documents over and over just to write a single entry in that sentence.

But even more important than that is the delicate nature of the expressions. Getting that > in the right place is tricky (it’s used when you look up a key from a group). The prefix notation helps out a bit here, but it’s still tricky. Next off, some of the formatters (“l” vs “c”) have very specific data types they require as input.

As a first goal, the error reporting needs to be much more expressive. It currently gives a vague response about the parameters, which only makes sense if you know what the engine is doing deep under the covers. This could be solved by unwinding the error parameters as the stack is popped back up to the top, so the end-user can better tell the source of the problem. The errors are already expressed as a i18n message object, so this shouldn’t be too difficult. The formatter for the final error reporting will need to be smart about how to translate type names, which means the error parameters need to be clear about the data type they hold (a “type string” versus a “format string” and so on).

The long term goals are to:

  • Create an editor to make lookups easy. Type-ahead is a must.
  • Be able to test out text templates to check for potential problems. This means using the matching system to see its context rules and checking if the values match up with those rules.

It’s that last point that seems do-able, but could be really tricky to get right. But getting it right is of the utmost importance.