Advanced SISR Results

This article assumes you are comfortable with the fundamentals covered in Intro to Semantic Interpretation — what SISR is, and how tags embed ECMAScript in a grammar. Here we go further, using moderately advanced ECMAScript to shape the results a grammar returns.

Using ECMAScript Within Tags

Tags are how semantic interpretation is embedded in a grammar, and a tag almost always contains ECMAScript. The recognizer executes the script in a tag as soon as the portion of the rule to its left is matched.

Because ECMAScript (sometimes called JavaScript) is a full scripting language, it can do far more than assign a literal value: it can build structured results, declare and reuse variables, and define functions. You will not need that power in every grammar, but when result handling gets complex, it collapses a great deal of branching into a few lines. The rest of this article works through that kind of case.

Important Reminders

Like any language, ECMAScript inside a grammar has syntax rules that are easy to get wrong — often in ways the recognizer will not catch until run time. A few are worth calling out before the example.

Whitespace

Whitespace — carriage returns, line feeds, spaces, tabs — is ignored when the recognizer processes ECMAScript. That leaves you free to format tags across multiple lines, with indentation that makes them readable and maintainable. For instance, this:

is processed identically to this:

The second form is far easier to read and maintain, but to the ASR the two are exactly the same.

Curly Brackets

ECMAScript also reserves the curly brace for its own blocks — conditionals, function bodies, and so on — which collides with the braces that delimit an SISR tag. When a tag’s code needs braces of its own, delimit the tag with the three-character sequences {!{ to open and }!} to close.

A simple tag with no internal braces can use a single pair:

But if your code uses a brace of its own — here, an if/else — wrap the tag in the three-character sequences:

Using a single brace in that second case produces an SISR parsing error. These errors are easy to miss: they surface only after a decode, so nothing flags them while the grammar is loaded or compiled.

Variable Declaration

A common misconception concerns variables. The out variable is predefined, so a grammar never declares it — which leads many authors to assume the same of every other variable. It is not true, and the result is undefined-variable errors that are, again, hard to detect.

ECMAScript is loosely typed: a single variable can hold a string, an integer, a floating-point value, an array, an object, or other types:

Any variable other than out must be declared before use, and given a type where it matters:

Note the var keyword declaring res; without it, the reference is a processing error. Assigning "string" does two things — it gives res a value and, more importantly, initializes it as a string, so the ECMAScript processor treats it as a string from then on. A variable with no clear type produces undefined behavior: had res never been assigned, copying it into out would return an undefined SISR result.

Functions

An often-overlooked capability is the ability to define and call functions. A function can process variables, perform on-the-fly checks, or simply factor out logic that would otherwise be repeated across several tags.

The following grammar defines a function and calls it each time the $option rule matches:

ABNF format:

The function keyword declares add_to_array, which pushes what_to_add onto array_to_fill and returns the array. Note the tag at the start of $rootrule: it initializes out as an Array. That step is essential — the tag after $option treats out as an array, and without the initialization it would error.

The equivalent grammar in GrXML defines the same tags:

GrXML format:

Saying "cat dog" against either grammar returns an array of the animals spoken:

An Example Grammar

With those techniques in hand, consider a concrete requirement that needs real logic. You want the caller to be able to say any combination of up to three of "cat", "dog", or "mouse", in any order. With optional words and a repeat operator, that much is straightforward.

Now add a constraint: no word may be counted twice. You could enumerate every allowed combination — there would be many — or you could let ECMAScript do the work and keep the grammar compact:

ABNF:

GrXML:

The built-in indexOf() method checks whether an animal has already been seen, preventing duplicates; the if statement then branches on the result.

For a new (non-duplicate) animal, the code appends a separating space to out.selections when it is non-empty, adds the animal, pushes it onto out.res_array, and increments out.num_animals. For a duplicate, it simply increments out.skipped.

All of these out sub-variables appear in the interpretation result. Note again the tag that runs before the repeated rule, which declares and initializes the variables — the step it is easiest to forget.

For both grammars, saying "cat dog" returns:

which carries several parameters:

• num_animals — the number of unique animals spoken
• res_array — an array with one item per unique animal
• selections — a string of the unique animal names, space-separated
• skipped — the number of skipped (duplicate) animals

Saying a repeated animal, such as "cat dog cat", gives a similar result, except skipped is 1 rather than 0 — flagging the second "cat" as a duplicate:

Conclusion

Combined, these techniques let you compute structured, deduplicated, application-ready results inside the grammar itself — turning what would otherwise be substantial post-processing code into a handful of tags.

Related Articles

• Intro to Semantic Interpretation
• SISR Basics
• Rule Variables
• SI Script by Example
• Getting the Return Value
• Converting from Older SISR