Add some basic documentation on lookahead assertions.
Chris Pressey
11 months ago
0 | Lookahead Assertions | |
1 | ==================== | |
2 | ||
3 | Fountain has (or will have) a general notion of lookahead assertions. | |
4 | ||
5 | A lookahead assertion is a constraint that says, "at this point, if | |
6 | we tried to parse S (where S is some sub-grammar), we would succeed". | |
7 | ||
8 | There are a few things to note about them. | |
9 | ||
10 | A lookahead assertion does not consume any input. | |
11 | ||
12 | In the presence of lookahead assertions, an ordered choice operator | |
13 | is not necessary, because ordered choice can be simulated. Suppose | |
14 | ordered choice is denoted by `/`, and `?A` is our lookahead assertion | |
15 | operator. Then | |
16 | ||
17 | A / B == ?B A | B | |
18 | ||
19 | Lookahead assertions can also serve the same function as conjunctive | |
20 | grammars; we can assert that the tokens to come conform to one | |
21 | syntactic structure, and actually parse a second syntactic structure, | |
22 | meaning the parse will only succeed if the string conforms to both | |
23 | structures -- the same as conjunction in conjuctive grammars. | |
24 | ||
25 | Lookahead assertions only make sense during parsing, so in the context | |
26 | of Fountain, we need to figure out what to do with them during generation. | |
27 | ||
28 | We will disgregard them completely during generation. They do not | |
29 | evaluate to either true or false; they are simply not evaluated at all. | |
30 | They are removed from the constraint expressions that will be evaluated. |