You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/Language/grammar_tutorial.pod6
+21-5Lines changed: 21 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -187,7 +187,7 @@ This results in any URI coming in getting checked; where the second string betwe
187
187
188
188
There is another way, though, that can give you far greater flexibility to do interesting or unholy things with your regexes, and provide some better readability when options grow large. These are proto-regexes.
189
189
190
-
To utilize these multimethods (here called protoregexes) to constrain our command to the same values we had above, we'll replace "token command" with the following:
190
+
To utilize these multimethods (here called proto-regexes) to constrain our command to the same values we had above, we'll replace "token command" with the following:
191
191
192
192
=begincode
193
193
proto token command {*}
@@ -197,7 +197,23 @@ To utilize these multimethods (here called protoregexes) to constrain our comman
197
197
token command:sym<delete> { <sym> }
198
198
=endcode
199
199
200
-
Using protoregexes like this gives us some greater flexibility. For example, instead of returning <sym>, which is the string that was matched, we could instead enter our own string, or do other funny stuff. We could do the same with the "token subject" method, and limit it also to only parsing correctly on valid subjects (like 'part' or 'people', etc.).
200
+
The 'sym' keyword is used to create the various proto-regex options. Each option
201
+
is named (ie. sym<update>), and for that option's use, a special <sym> token is
202
+
auto-generated, that is the case-sensitive string-literal of the name assigned.
203
+
204
+
The <sym> token, as well as other user-defined tokens, may be used in the proto-
205
+
regex option block to define the specific 'match condition'. Regex tokens are
206
+
compiled forms, and once defined cannot subsequently be modified by adverb
207
+
actions (eg. :i). Therefore, as it's auto-generated, the special <sym> token is
208
+
useful only where an exact match of the option name is required.
209
+
210
+
If, for one of the proto-regex options, a match condition occurs, then the whole
211
+
proto's search terminates. The matching data, in the form of a match object, is
212
+
assigned to the parent proto token. If the special <sym> token was employed, and
213
+
formed all or part of the actual match, then it is preserved as a sublevel in
214
+
the match object, otherwise it is absent.
215
+
216
+
Using proto-regexes like this gives us some greater flexibility. For example, instead of returning <sym>, which in this case is the entire string that was matched, we could instead enter our own string, or do other funny stuff. We could do the same with the "token subject" method, and limit it also to only parsing correctly on valid subjects (like 'part' or 'people', etc.).
201
217
202
218
=head2Putting our RESTful grammar together so far
203
219
@@ -342,7 +358,7 @@ To do this, all we have to do is add the method TOP to our action class, and in
342
358
{
343
359
method TOP ($/) {
344
360
make { subject => $<subject>.Str,
345
-
command => $<command><sym>.Str,
361
+
command => $<command>.Str,
346
362
data => $<data>.made }
347
363
}
348
364
@@ -386,7 +402,7 @@ Oh, did we forget to get rid of that ugly array element number? Hmm. Let's make
386
402
{
387
403
method TOP ($/) {
388
404
make { subject => $<subject>.Str,
389
-
command => $<command><sym>.Str,
405
+
command => $<command>.Str,
390
406
data => $<data>.made,
391
407
subject-id => $<data>.made[0] }
392
408
}
@@ -430,7 +446,7 @@ And this is the grammar and grammar actions that got us there, to recap:
0 commit comments