meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
choice_points [2020/09/27 00:01] – [Semantic Lookahead] revusky | choice_points [2021/02/08 18:09] (current) – ↷ Links adapted because of a move operation revusky | ||
---|---|---|---|
Line 7: | Line 7: | ||
* The expansions within a //choice construct//, | * The expansions within a //choice construct//, | ||
- | (Perhaps needless to say, all of the above constructs | + | (Perhaps needless to say, all of these constructs arbitrarily combine and nest within one another to an arbitrary level of complexity.) |
- | I think the simplest way to think about the above cases (for most people, anyway) is just in terms of their analogues in a procedural programming language. The first three cases are effectively binary choices, a choice between entering the expansion inside the parentheses and jumping directly to what follows it. In all of these cases, the expansion within the parentheses is a choice point. The last case is a choice between n options and each of the expansions is a choice point. | + | I think the simplest way to think about the above cases (for most people, anyway) is just in terms of their analogues in a procedural programming language. The first three cases are effectively binary choices, a choice between entering the expansion inside the parentheses and jumping directly to what follows it. In all of these cases, the expansion within the parentheses is a choice point. The last case is a choice between n options and each of those n sub-expansions is a choice point in the grammar. |
- | ==== Zero Or More ==== | + | ==== Zero Or One ==== |
- | A //zero-or-more// is a single (non-looping) choice. If the enclosed expansion matches, we enter it, and if not, we jump directly to whatever follows it. So, if we write: | + | A //zero-or-one// is a single (non-looping) choice. If the enclosed expansion matches, we enter it, and if not, we jump directly to whatever follows it. So, if we write: |
< | < | ||
Line 83: | Line 83: | ||
.... | .... | ||
else | else | ||
- | | + | |
</ | </ | ||
Line 104: | Line 104: | ||
Now, to be clear, looking ahead one token might be sufficient or not in any given spot, but if we don't specify any extra information, | Now, to be clear, looking ahead one token might be sufficient or not in any given spot, but if we don't specify any extra information, | ||
- | //We enter an expansion at a choice point if the next token is in that expansion' | + | //We enter an expansion at a choice point if the next token is in that expansion' |
- | Again, no need to be intimidated by the lingo. An expansion' | + | Again, no need to be intimidated by the lingo. An expansion' |
- | //If the next token is **not** in an expansion' | + | //If the next token is **not** in an expansion' |
Now, regardless, it may be the case that more than one of the expansions at a given choice point matches this condition. Well, in that case, we have a secondary rule: //the first one gets it//. And this is really no different, by the way, from how if-elseif-else in a procedural programming language works. | Now, regardless, it may be the case that more than one of the expansions at a given choice point matches this condition. Well, in that case, we have a secondary rule: //the first one gets it//. And this is really no different, by the way, from how if-elseif-else in a procedural programming language works. | ||
Line 173: | Line 173: | ||
===== More than one way to skin a cat... ===== | ===== More than one way to skin a cat... ===== | ||
- | The //definite numerical lookahead// of two tokens worked okay in the above example, but generally speaking, it is a rather crude disposition. The legacy JavaCC tool provides two other ways to specify how we resolve a choice -- when the default resolution is not good enough. In the original, somewhat inaccurate terminology, | + | The //definite numerical lookahead// of two tokens worked okay in the above example, but generally speaking, it is a rather crude disposition. The legacy JavaCC tool provides two other ways to specify how we resolve a choice -- when the default resolution is not good enough. In the original, somewhat inaccurate terminology, |
==== Syntactic Lookahead ==== | ==== Syntactic Lookahead ==== | ||
Line 233: | Line 233: | ||
In very many common usage cases, the [[up to here]] syntax removes the need to write separate // | In very many common usage cases, the [[up to here]] syntax removes the need to write separate // | ||
- | By the same token, //semantic lookahead//, | + | By the same token, //semantic lookahead//, |
- | A general rule of thumb would be to use [[up to here]] and [[lookbehind]] constructs whenever possible instead of // | + | A general rule of thumb would be to use [[up to here]] and [[contextual_predicates]] constructs whenever possible instead of // |