Named literals

Scripts > Token definitions > Literals > Named literals

Sometimes it is advisable to define named literal tokens instead of using simple literal tokens. Either this can be done directly on the token page or you simply can define them within a production too, by putting an underscore in front of the literal text. In this case a new token is inserted on the token page automatically, as soon as the production is accepted. If e.g. the expression _TETRA occurs in the production, then the following token is produced:

Since special characters aren't permitted in script names, this way no tokens which include special characters can be defined. However, it is possible to change the definition of a named literal afterwards correspondingly. E.g.:

If the name of a token starts with an underscore, all characters occurring in the definition are interpreted literally. So the stars '*' don't have the meaning of repeat marks here.

The advantages of named literal tokens are that they

to 1.

Misspellings which could occur if the same literal is used in different places of the grammar are avoided.

to 2.

If the same semantic action shall always be executed when finding a certain literal token in the text even if it occurres in different places of the grammar, then it is appropriate to make use of the possibility of connecting a token directly with an action. E.g. it often makes sense at the generation of parse trees to insert the texts of the literal tokens as leafs in the tree in always the same way.

to 3.

A character string is produced at the generation of c++ code from a project for every named literal. These strings can be used also in the code of the program, which uses the parser. For example:

const char _protected[] = "protected";

This page belongs to the TextTransformer Documentation