@@ -83,33 +83,33 @@ C<JSON::Tiny::Grammar.parse($tester)> attempts to match the regex named
83
83
C<TOP> to the string C<$tester>.
84
84
85
85
However, the example code does not seem to have a regex named C<TOP>; it
86
- has a I<rule> named C<TOP>. What's the difference? A rule is a regex
87
- with special behavior. Within a rule, sequences of whitespace are deemed
88
- significant and will match actual whitespace within the string (this is
89
- equivalent to using the C<:sigspace> modifier). Looking at the grammar,
90
- you'll also note that there are also C<token> declarations as well. A
91
- C<token> is also a regex with special behavior. A C<token> is the same
92
- as a rule (has significant whitespace), but it also does not backtrack
93
- so that when a partial pattern match fails, the regex engine will not go
94
- back and try another alternative (this is equivalent to using the
95
- C<:ratchet> modifier).
86
+ has a I<rule> named C<TOP>. Looking at the grammar, you'll also note
87
+ that there are also C<token> declarations as well. What's the
88
+ difference? Each of the C<token> and C<rule> declarations are just
89
+ C<regex> declarations with special default behavior. A C<token> declares
90
+ a regex that does not backtrack by default, so that when a partial
91
+ pattern match fails, the regex engine will not go back up and try
92
+ another alternative (this is equivalent to using the C<:ratchet>
93
+ modifier). A C<rule> will also not backtrack by default, additionally,
94
+ sequences of whitespace are deemed significant and will match actual
95
+ whitespace within the string using the built-in C<< <ws> >> rule (this
96
+ is equivalent to using the C<:sigspace> modifier).
96
97
97
98
=for author
98
99
99
- Add code to POD processor that does the right thing with L<S??> and
100
- L<src/...> links. Or update this document appropriately.
100
+ Add code to POD processor that does the right thing with L<S??> links.
101
101
102
102
=end author
103
103
104
- See L<src/regex > for more information on modifiers and how they may be
104
+ See L<sec:regexes > for more information on modifiers and how they may be
105
105
used or look at L<S05>.
106
106
107
107
Usually, when talking about regex that are rules or tokens, we tend to
108
108
call them rules or tokens rather than the more general term "regex", to
109
109
distinguish their special behaviors.
110
110
111
- In this example, the C<TOP> rule anchors the match to the start and end
112
- of the string, so that the whole string has to be in valid JSON format
111
+ In this example, the C<TOP> rule anchors the match to the start (with C<^>) and end
112
+ of the string (with C<$>) , so that the whole string has to be in valid JSON format
113
113
for the match to succeed. After matching the anchor at the start of the
114
114
string, the regex attempts to match either an C<< <array> >> or an C<<
115
115
<object> >>. Enclosing a regex name in angle brackets causes the regex
@@ -219,7 +219,7 @@ The first two lines introduce a grammar that inherits from
219
219
C<JSON::Tiny::Grammar>. Just as subclasses inherit methods from superclasses,
220
220
so grammars inherit rules from its base grammar. Any rule used within
221
221
the grammar will be looked for first in the grammar in which it was used,
222
- then within its parent grammar .
222
+ then within its parent(s) .
223
223
224
224
In this minimal JSON grammar, whitespace is never mandatory, so C<ws>
225
225
can match nothing at all. After optional spaces, two slashes C<'//'>
@@ -248,7 +248,7 @@ ordinary, C<|> delimited alternatives.
248
248
X<reduction methods>
249
249
X<action methods>
250
250
251
- The C<parse> method of a grammar returns a C<Match> object through which
251
+ The C<. parse> method of a grammar returns a C<Match> object through which
252
252
you can access all the relevant information of the match. Named regex
253
253
that match within the grammar may be accessed via the C<Match> object
254
254
similar to a hash where the keys are the regex names and the values are
@@ -259,10 +259,12 @@ parentheses are available as positional elements of the C<Match> object
259
259
260
260
Once you have the Match object, what can you I<do> with it? You could
261
261
recursively traverse this object and create data structures based on what
262
- you find or execute code. An alternative solution exists : I<action methods>.
262
+ you find or execute code. Perl 6 provides another alternative : I<action methods>.
263
263
264
264
=begin programlisting
265
265
266
+ # JSON::Tiny::Grammar as above
267
+ # ...
266
268
class JSON::Tiny::Actions {
267
269
method TOP($/) { make $/.values.[0].ast }
268
270
method object($/) { make $<pairlist>.ast.hash }
@@ -305,9 +307,10 @@ you find or execute code. An alternative solution exists: I<action methods>.
305
307
306
308
This example passes an actions object to the grammar's C<parse> method.
307
309
Whenever the grammar engine finishes parsing a regex, it calls a method on
308
- the actions object with the same name as the current regex. If no such method
309
- exists, the grammar engine moves along. If a method does exist, the grammar
310
- engine passes the current match object as a positional argument.
310
+ the actions object with the same name as the regex. If no such method
311
+ exists, the grammar engine continues parsing the rest of the grammar. If
312
+ a method does exist, the grammar engine passes the current match object
313
+ as a positional argument.
311
314
312
315
X<abstract syntax tree>
313
316
X<AST>
0 commit comments