@@ -57,7 +57,7 @@ grammar defined, you call it and pass in a string for parsing.
57
57
58
58
Now, you may be wondering, if I have all these regexes defined that just return
59
59
their results, how does that help with parsing strings that may be ahead
60
- or backwards in a string, or things that need to be combined from many of
60
+ or backwards in another string, or things that need to be combined from many of
61
61
those regexes... And that's where grammar actions come in.
62
62
63
63
For every "method" you match in your grammar, you get an action you can use
@@ -70,17 +70,17 @@ method is called C<TOP> by default.
70
70
As already mentioned, grammars are declared using the I < grammar > keyword and its
71
71
"methods" are declared with I < regex > , or I < token > , or I < rule > .
72
72
73
- = item Regex methods are slow but thorough, which will look back in the string
73
+ = item Regex methods are slow but thorough, they will look back in the string
74
74
and really try.
75
75
76
76
= item Token methods are faster than regex methods and ignore whitespace.
77
77
78
78
= item Rule methods are the same as token methods except whitespace
79
79
is not ignored.
80
80
81
- When a method (regex, token or rule) matches in the grammar,
82
- the string matched is put into a L < match object|/type/Match > and
83
- keyed with the same name as the method.
81
+ When a method (regex, token or rule) matches in the grammar, the string matched
82
+ is put into a L < match object|/type/Match > and keyed with the same name as the
83
+ method.
84
84
85
85
= begin code
86
86
grammar G {
@@ -92,7 +92,25 @@ keyed with the same name as the method.
92
92
If you were to use C < my $match = G.parse($string) > and your
93
93
string started with 'clever_text_keyword', you would get a match
94
94
object back that contained 'clever_text_keyword' keyed by
95
- the name of C « <thingy> » in your match object.
95
+ the name of C « <thingy> » in your match object. For instance:
96
+
97
+ = begin code
98
+ grammar G {
99
+ token TOP { <thingy> .* }
100
+ token thingy { 'Þor' }
101
+ }
102
+
103
+ my $match = G.parse("Þor is mighty");
104
+ say $match.perl; # OUTPUT: «Match.new(made => Any, pos => 13, orig => "Þor is mighty",...»
105
+ say $/.perl; # OUTPUT: «Match.new(made => Any, pos => 13, orig => "Þor is mighty",...»
106
+ say $/<thingy>.perl;
107
+ # OUTPUT: «Match.new(made => Any, pos => 3, orig => "Þor is mighty", hash => Map.new(()), list => (), from => 0)»
108
+ = end code
109
+
110
+ The two first output lines show that C < $match > contains a C < Match > objects with
111
+ the results of the parsing; but those results are also assigned to the L < match variable C < $/ > |/syntax/$$SOLIDUS > .
112
+ Either match object can be keyed, as
113
+ indicated above, by C < thingy > to return the match for that particular C < token > .
96
114
97
115
The C < TOP > method (whether regex, token, or rule) is the overarching pattern
98
116
that must match everything (by default). If the parsed string doesn't
0 commit comments