|Top Previous Next|
There are three options for the SKIP symbol which control the treatment of possible conflicts. Two of this can get predefined in the project options. If a not predefined option shall be used, then this can be expressed by appending a parameter to "SKIP". E.g.
SKIP[ F ]
1. no failure alternative
If the use of global scanners is set in the project options, it can happen that at the current position of the source text a token which isn't expected in the grammar is recognized. For example regular expression for identifiers is defined in many projects. If now
is used to parse
"hello" would be interpreted as an identifier. According to the scanner algorithm, SKIP wouldn't be tested. Instead an error message would be produced. If no failure alternatives are permitted, however, "hello" becomes skipped and therefore the complete text would be parsed correctly.
Within a production this option can be set explicitly with the parameter NFA (no failure alternative):
SKIP[ NFA ]
There is a problem with hidden alternatives at this option, though. Example:
( ID ";"* )* SKIP
If a text starts with a semicolon, then it is skipped with SKIP. If the text starts with an identifier on which a semicolon follows, then the identifier is recognized correctly. However, the semicolon is skipped again. Although it is recognized at first it is not judged to be an alternative to SKIP. In this case the strict option 3 would be adequate for SKIP (see below)
2. allow skip destinations at the current position // experimentally
Ein ähnlicher Konflikt wie eben beschrieben entsteht, wenn schon an der aktuellen Position des Quelltextes ein Token erkannt wird, das als Ziel des SKIP-Knotens gesetzt ist.
A similar conflict as just described arises if a token which is the destination of SKIP, is already recognized at the current position of the source text.
The word "Hello" in the text:
then would be recognized as identifier. The option described above, not to allow failure alternatives, would not help, since the skip destinations aren't part of these alternatives. If they were added, an expression like
would become senseless. SKIP would always match on the text (if not at the end with no following identifier). So it is to recommend to amend the grammar correspondingly: With
"Hello world" is parsed correctly. Experimentally there is the NF-option (no failure)
SKIP[ NF ] // experimentally
This option possibly will be no longer available in future TETRA versions, if not desired by users.
3. strict generation of errors
Errors were always caused up to TextTransformer 1.5.0 in the cases represented above. This option forces the programmer to consider and to treat conflicts explicitly. The possibility of making SKIP optionally was already mentioned. One other possibility would be:
( SKIP | ID ) ID
A strict generation of errors can be forced in a production with the F parameter:
SKIP[ F ]
It shall be pointed out again that the mentioned conflict possibilities result from the option to use global scanners. A conflict with literals only can arise if also the option to test all literals is set and a literal is an immediate alternative to SKIP. Otherwise literals aren't tested at all.
This page belongs to the TextTransformer Documentation
|Home Content German|