1XS::Parse::Keyword(3pm)User Contributed Perl DocumentatioXnS::Parse::Keyword(3pm)
2
6 "XS::Parse::Keyword" - XS functions to assist in parsing keyword syntax
7
9 This module provides some XS functions to assist in writing syntax
10 modules that provide new perl-visible syntax, primarily for authors of
11 keyword plugins using the "PL_keyword_plugin" hook mechanism. It is
12 unlikely to be of much use to anyone else; and highly unlikely to be
13 any use when writing perl code using these. Unless you are writing a
14 keyword plugin using XS, this module is not for you.
15 This module is also currently experimental, and the design is still
17 evolving and subject to change. Later versions may break ABI
18 compatibility, requiring changes or at least a rebuild of any module
19 that depends on it.
20
22 boot_xs_parse_keyword
23 void boot_xs_parse_keyword(double ver);
24 Call this function from your "BOOT" section in order to initialise the
26 module and parsing hooks.
27 ver should either be 0 or a decimal number for the module version
29 requirement; e.g.
30 boot_xs_parse_keyword(0.14);
32 register_xs_parse_keyword
34 void register_xs_parse_keyword(const char *keyword,
35 const struct XSParseKeywordHooks *hooks, void *hookdata);
36 This function installs a set of parsing hooks to be associated with the
38 given keyword. Such a keyword will then be handled automatically by a
39 keyword parser installed by "XS::Parse::Keyword" itself.
40
42 The "XSParseKeywordHooks" structure provides the following hook stages,
43 which are invoked in the given order.
44 flags
46 The following flags are defined:
47 "XPK_FLAG_EXPR"
49 The parse or build function is expected to return
50 "KEYWORD_PLUGIN_EXPR".
51 "XPK_FLAG_STMT"
53 The parse or build function is expected to return
54 "KEYWORD_PLUGIN_STMT".
55 These two flags are largely for the benefit of giving static
57 information at registration time to assist static parsing or other
58 related tasks to know what kind of grammatical element this keyword
59 will produce.
60 "XPK_FLAG_AUTOSEMI"
62 The syntax forms a complete statement, which should be followed by
63 a statement separator semicolon (";"). This semicolon is optional
64 at the end of a block.
65 The semicolon, if present, will be consumed automatically.
67 "XPK_FLAG_BLOCKSCOPE"
69 The entire parse and build process will be wrapped in a pair of
70 block_start() and block_end() calls. This ensures that, for
71 example, any newly-introduced lexical variables do not escape from
72 the scope of the syntax created by the keyword.
73 The "permit" Stage
75 const char *permit_hintkey;
76 bool (*permit) (pTHX_ void *hookdata);
77 Called by the installed keyword parser hook which is used to handle
79 keywords registered by "register_xs_parse_keyword".
80 As a shortcut for the common case, the "permit_hintkey" may point to a
82 string to look up from the hints hash. If the given key name is not
83 found in the hints hash then the keyword is not permitted. If the key
84 is present then the "permit" function is invoked as normal.
85 If not rejected by a hint key that was not found in the hints hash, the
87 function part of the stage is called next and should inspect whether
88 the keyword is permitted at this time perhaps by inspecting other
89 lexical clues, and return true only if the keyword is permitted.
90 Both the string and the function are optional. Either or both may be
92 present. If neither is present then the keyword is always permitted -
93 which is likely not what you wanted to do.
94 The "check" Stage
96 void (*check)(pTHX_ void *hookdata);
97 Invoked once the keyword has been permitted. If present, this hook
99 function can check the surrounding lexical context, state, or other
100 information and throw an exception if it is unhappy that the keyword
101 should apply in this position.
102 The "parse" Stage
104 This stage is invoked once the keyword has been checked, and actually
105 parses the incoming text into an optree. It is implemented by calling
106 the first of the following function pointers which is not NULL. The
107 invoked function may optionally build an optree to represent the parsed
108 syntax, and place it into the variable addressed by "out". If it does
109 not, then a simple "OP_NULL" will be constructed in its place.
110 lex_read_space() is called both before and after this stage is invoked,
112 so in many simple cases the hook function itself does not need to
113 bother with it.
114 int (*parse)(pTHX_ OP **out, void *hookdata);
116 If present, this should consume text from the parser buffer by invoking
118 "lex_*" or "parse_*" functions and eventually return a
119 "KEYWORD_PLUGIN_*" result value.
120 This is the most generic and powerful of the options, but requires the
122 most amount of implementation work.
123 int (*build)(pTHX_ OP **out, XSParseKeywordPiece *args[], size_t nargs, void *hookdata);
125 If "parse" is not present, this is called instead after parsing a
127 sequence of arguments, of types given by the pieces field; which should
128 be a zero- terminated array of piece types.
129 This alternative is somewhat less generic and powerful than providing
131 "parse" yourself, but involves much less parsing work and is shorter
132 and easier to implement.
133 int (*build1)(pTHX_ OP **out, XSParseKeywordPiece *arg0, void *hookdata);
135 If neither "parse" nor "build" are present, this is called as a simpler
137 variant of "build" when only a single argument is required. It takes
138 its type from the "piece1" field instead.
139
141 When using the "build" or "build1" alternatives for the "parse" phase,
142 the actual syntax is parsed automatically by this module, according to
143 the specification given by the pieces or piece1 field. The result of
144 that parsing step is placed into the args or arg0 parameter to the
145 invoked function, using a "struct" type consisting of the following
146 fields:
147 typedef struct
149 union {
150 OP *op;
151 CV *cv;
152 SV *sv;
153 int i;
154 struct {
155 SV *name;
156 SV *value;
157 } attr;
158 PADOFFSET padix;
159 struct XSParseInfixInfo *infix;
160 };
161 int line;
162 } XSParseKeywordPiece;
163 Which field of the anonymous union is set depends on the type of the
165 piece. The line field contains the line number of the source file
166 where parsing of that piece began.
167 Some piece types are "atomic", whose definition is self-contained.
169 Others are structural, defined in terms of inner pieces. Together these
170 form an entire tree-shaped definition of the syntax that the keyword
171 expects to find.
172 Atomic types generally provide exactly one argument into the list of
174 args (with the exception of literal matches, which do not provide
175 anything). Structural types may provide an initial argument
176 themselves, followed by a list of the values of each sub-piece they
177 contained inside them. Thus, while the data structure defining the
178 syntax shape is a tree, the argument values it parses into is passed as
179 a flat array to the "build" function.
180 Some structural types need to be able to determine whether or not
182 syntax relating some optional part of them is present in the incoming
183 source text. In this case, the pieces relating to those optional parts
184 must support "probing". This ability is also noted below.
185 The type of each piece should be one of the following macro values.
187 XPK_BLOCK
189 atomic, can probe, emits op.
190 XPK_BLOCK
192 A brace-delimited block of code is expected, passed as an optree in the
194 op field. This will be parsed as a block within the current function
195 scope.
196 This can be probed by checking for the presence of an open-brace ("{")
198 character.
199 Be careful defining grammars with this because an open-brace is also a
201 valid character to start a term expression, for example. Given a choice
202 between "XPK_BLOCK" and "XPK_TERMEXPR", either of them could try to
203 consume such code as
204 { 123, 456 }
206 XPK_BLOCK_VOIDCTX, XPK_BLOCK_SCALARCTX, XPK_BLOCK_LISTCTX
208 Variants of "XPK_BLOCK" which wrap a void, scalar or list-context scope
209 around the block.
210 XPK_PREFIXED_BLOCK
212 structural, emits op.
213 XPK_PREFIXED_BLOCK(pieces ...)
215 Some pieces are expected, followed by a brace-delimited block of code,
217 which is passed as an optree in the op field. The prefix pieces are
218 parsed first, and their results are passed before the block itself.
219 The entire sequence, including the prefix items, is contained within a
221 pair of block_start() / block_end() calls. This permits the prefix
222 pieces to introduce new items into the lexical scope of the block - for
223 example by the use of "XPK_LEXVAR_MY".
224 A call to intro_my() is automatically made at the end of the prefix
226 pieces, before the block itself is parsed, ensuring any new lexical
227 variables are now visible.
228 In addition, the following extra piece types are recognised here:
230 XPK_SETUP
232 void setup(pTHX_ void *hookdata);
233 XPK_SETUP(&setup)
235 atomic, emits nothing.
237 This piece type runs a function given by pointer. Typically this
239 function may be used to introduce new lexical state into the
240 parser, or in some other way have some side-effect on the parsing
241 context of the block to be parsed.
242 XPK_PREFIXED_BLOCK_ENTERLEAVE
244 A variant of "XPK_PREFIXED_BLOCK" which additionally wraps the entire
245 parsing operation, including the block_start(), block_end() and any
246 calls to "XPK_SETUP" functions, within a "ENTER"/"LEAVE" pair.
247 This should not make a difference to the standard parser pieces
249 provided here, but may be useful behaviour for the code in the setup
250 function, especially if it wishes to modify parser state and use the
251 savestack to ensure it is restored again when parsing has finished.
252 XPK_ANONSUB
254 atomic, emits cv.
255 A brace-delimited block of code is expected, and assembled into the
257 body of a new anonymous subroutine. This will be passed as a protosub
258 CV in the cv field.
259 XPK_STAGED_ANONSUB
261 XPK_STAGED_ANONSUB(stages ...)
262 structural, emits cv.
264 A variant of "XPK_ANONSUB" which accepts additional function pointers
266 to be invoked at various points during parsing and compilation. These
267 can be used to interrupt the normal parsing in a manner similar to
268 XS::Parse::Sublike, though currently somewhat less flexibly.
269 The stages list may contain elements of the following types. Not every
271 stage must be present, but any that are present must be in the
272 following order. Multiple copies of each stage are permitted; they are
273 invoked in the written order, with parser code happening inbetween.
274 XPK_ANONSUB_PREPARE
276 XPK_ANONSUB_PREPARE(&callback)
277 atomic, emits nothing.
279 Invokes the callback before start_subparse().
281 XPK_ANONSUB_START
283 XPK_ANONSUB_START(&callback)
284 atomic, emits nothing.
286 Invokes the callback after block_start() but before parsing the
288 actual block contents.
289 XPK_ANONSUB_END
291 OP *op_wrapper_callback(pTHX_ OP *o, void *hookdata);
292 XPK_ANONSUB_END(&op_wrapper_callback)
294 atomic, emits nothing.
296 Invokes the callback after parsing the block contents but before
298 calling block_end(). The callback may modify the optree if required
299 and return a new one.
300 XPK_ANONSUB_WRAP
302 XPK_ANONSUB_WRAP(&op_wrapper_callback)
303 atomic, emits nothing.
305 Invokes the callback after block_end() but before passing the
307 optree to newATTRSUB(). The callback may modify the optree if
308 required and return a new one.
309 XPK_ARITHEXPR
311 atomic, emits op.
312 XPK_ARITHEXPR
314 An arithmetic expression is expected, parsed using parse_arithexpr(),
316 and passed as an optree in the op field.
317 XPK_ARITHEXPR_VOIDCTX, XPK_ARITHEXPR_SCALARCTX
319 Variants of "XPK_ARITHEXPR" which puts the expression in void or scalar
320 context.
321 XPK_TERMEXPR
323 atomic, emits op.
324 XPK_TERMEXPR
326 A term expression is expected, parsed using parse_termexpr(), and
328 passed as an optree in the op field.
329 XPK_TERMEXPR_VOIDCTX, XPK_TERMEXPR_SCALARCTX
331 Variants of "XPK_TERMEXPR" which puts the expression in void or scalar
332 context.
333 XPK_PREFIXED_TERMEXPR_ENTERLEAVE
335 XPK_PREFIXED_TERMEXPR_ENTERLEAVE(pieces ...)
336 A variant of "XPK_TERMEXPR" which expects a sequence pieces first
338 before it parses a term expression, similar to how
339 "XPK_PREFIXED_BLOCK_ENTERLEAVE" works. The entire operation is wrapped
340 in an "ENTER"/"LEAVE" pair.
341 This is intended just for use of "XPK_SETUP" pieces as prefixes. Any
343 other pieces which actually parse real input are likely to cause
344 overly-complex, subtle, or outright ambiguous grammars, and should be
345 avoided.
346 XPK_LISTEXPR
348 atomic, emits op.
349 XPK_LISTEXPR
351 A list expression is expected, parsed using parse_listexpr(), and
353 passed as an optree in the op field.
354 XPK_LISTEXPR_LISTCTX
356 Variant of "XPK_LISTEXPR" which puts the expression in list context.
357 XPK_IDENT, XPK_IDENT_OPT
359 atomic, can probe, emits sv.
360 A bareword identifier name is expected, and passed as an SV containing
362 a PV in the sv field. An identifier is not permitted to contain a
363 double colon ("::").
364 The "_OPT"-suffixed version is optional; if no identifier is found then
366 sv is set to "NULL".
367 XPK_PACKAGENAME, XPK_PACKAGENAME_OPT
369 atomic, can probe, emits sv.
370 A bareword package name is expected, and passed as an SV containing a
372 PV in the sv field. A package name is similar to an identifier, except
373 it permits double colons in the middle.
374 The "_OPT"-suffixed version is optional; if no package name is found
376 then sv is set to "NULL".
377 XPK_LEXVARNAME
379 atomic, emits sv.
380 XPK_LEXVARNAME(kind)
382 A lexical variable name is expected, and passed as an SV containing a
384 PV in the sv field. The "kind" argument specifies what kinds of
385 variable are permitted, and should be a bitmask of one or more bits
386 from "XPK_LEXVAR_SCALAR", "XPK_LEXVAR_ARRAY" and "XPK_LEXVAR_HASH". A
387 convenient shortcut "XPK_LEXVAR_ANY" permits all three.
388 XPK_ATTRIBUTES
390 atomic, emits i followed by more args.
391 A list of ":"-prefixed attributes is expected, in the same format as
393 sub or variable attributes. An optional leading ":" indicates the
394 presence of attributes, then one or more of them are parsed. Attributes
395 may be optionally separated by additional ":"s, but this is not
396 required.
397 Each attribute is expected to be an identifier name, followed by an
399 optional value wrapped in parentheses. Whitespace is NOT permitted
400 between the name and value, as per standard Perl parsing rules.
401 :attrname
403 :attrname(value)
404 The i field indicates how many attributes were found. That number of
406 additional arguments are then passed, each containing two SVs in the
407 attr.name and attr.value fields. This number may be zero.
408 It is not an error for there to be no attributes present, or for the
410 optional colon to be missing. In this case i will be set to zero.
411 XPK_VSTRING, XPK_VSTRING_OPT
413 atomic, can probe, emits sv.
414 A version string is expected, of the form "v1.234" including the
416 leading "v" character. It is passed as a version SV object in the sv
417 field.
418 The "_OPT"-suffixed version is optional; if no version string is found
420 then sv is set to "NULL".
421 XPK_LEXVAR
423 atomic, emits padix.
424 XPK_LEXVAR(kind)
426 A lexical variable name is expected and looked up from the current pad.
428 The resulting pad index is passed in the padix field. No error happens
429 if the variable is not found; the value "NOT_IN_PAD" is passed instead.
430 The "kind" argument specifies what kinds of variable are permitted, as
432 per "XPK_LEXVARNAME".
433 XPK_LEXVAR_MY
435 atomic, emits padix.
436 XPK_LEXVAR_MY(kind)
438 A lexical variable name is expected, added to the current pad as if
440 specified in a "my" expression, and passed as the pad index in the
441 padix field.
442 The "kind" argument specifies what kinds of variable are permitted, as
444 per "XPK_LEXVARNAME".
445 XPK_COMMA, XPK_COLON, XPK_EQUALS
447 atomic, can probe, emits nothing.
448 A literal character (",", ":" or "=") is expected. No argument value is
450 passed.
451 XPK_AUTOSEMI
453 atomic, emits nothing.
454 A literal semicolon (";") as a statement terminator is optionally
456 expected. If the next token is a closing brace to indicate the end of
457 a block, then a semicolon is not required. If anything else is
458 encountered an error will be raised.
459 This piece type is the same as specifying the "XPK_FLAG_AUTOSEMI". It
461 is useful to put at the end of a sequence that forms part of a choice
462 of syntax, where some forms indicate a statement ending in a semicolon,
463 whereas others may end in a full block that does not need one.
464 XPK_INFIX_*
466 atomic, can probe, emits infix.
467 An infix operator as recognised by XS::Parse::Infix. The returned
469 pointer points to a structure allocated by "XS::Parse::Infix"
470 describing the operator.
471 Various versions of the macro are provided, each using a different
473 selection filter to choose certain available infix operators:
474 XPK_INFIX_RELATION # any relational operator
476 XPK_INFIX_EQUALITY # an equality operator like `==` or `eq`
477 XPK_INFIX_MATCH_NOSMART # any sort of "match"-like operator, except smartmatch
478 XPK_INFIX_MATCH_SMART # XPK_INFIX_MATCH_NOSMART plus smartmatch
479 XPK_LITERAL
481 atomic, can probe, emits nothing.
482 XPK_LITERAL("literal")
484 A literal string match is expected. No argument value is passed.
486 This form should generally be avoided if at all possible, because it is
488 very easy to abuse to make syntaxes which confuse humans and code tools
489 alike. Generally it is best reserved just for the first component of a
490 "XPK_OPTIONAL" or "XPK_REPEATED" sequence, to provide a "secondary
491 keyword" that such a repeated item can look out for.
492 XPK_KEYWORD
494 atomic, can probe, emits nothing.
495 XPK_KEYWORD("keyword")
497 A literal string match is expected. No argument value is passed.
499 This is similar to "XPK_LITERAL" except that it additionally checks
501 that the following character is not an identifier character. This
502 ensures that the expected keyword-like behaviour is preserved. For
503 example, given the input "keyword", the piece XPK_LITERAL("key") would
504 match it, whereas XPK_KEYWORD("key") would not because of the
505 subsequent "w" character.
506 XPK_INTRO_MY
508 atomic, emits nothing.
509 Calls the core perl intro_my() function immediately. No input is
511 consumed and no output value is generated. This is often useful after
512 "XPK_LEXVAR_MY".
513 XPK_WARNING
515 atomic, emits nothing.
516 XPK_WARNING("message here")
518 Emits a warning by calling the core perl warn() function on the given
520 string literal. This is equivalent to simply calling warn() from the
521 build function, except that it is emitted immediately at parse time, so
522 line numbering will be more accurate. Also, by placing it as part of an
523 optional or choice sequence, the warning will only be emitted
524 conditionally if that part of the grammar structure is encountered.
525 XPK_WARNING_...
527 Several variants of "XPK_WARNING" exist that are conditional on
528 particular warning categories being enabled. These are ones that are
529 likely to be useful at parse time:
530 XPK_WARNING_AMBIGUOUS
532 XPK_WARNING_DEPRECATED
533 XPK_WARNING_EXPERIMENTAL
534 XPK_WARNING_PRECEDENCE
535 XPK_WARNING_SYNTAX
536 XPK_SEQUENCE
538 structural, might support probe, emits nothing.
539 XPK_SEQUENCE(pieces ...)
541 A structural type which contains a number of pieces. This is normally
543 equivalent to simply placing the pieces in sequence inside their own
544 container, but it is useful inside "XPK_CHOICE" or "XPK_TAGGEDCHOICE".
545 An "XPK_SEQUENCE" supports probe if its first contained piece does;
547 i.e. is transparent to probing.
548 XPK_OPTIONAL
550 structural, emits i.
551 XPK_OPTIONAL(pieces ...)
553 A structural type which may expects to find its contained pieces, or is
555 happy not to. This will pass an argument whose i field contains either
556 1 or 0, depending whether the contents were found. The first piece type
557 within must support probe.
558 XPK_REPEATED
560 structural, emits i.
561 XPK_REPEATED(pieces ...)
563 A structural type which expects to find zero or more repeats of its
565 contained pieces. This will pass an argument whose i field contains the
566 count of the number of repeats it found. The first piece type within
567 must support probe.
568 XPK_CHOICE
570 structural, can probe, emits i.
571 XPK_CHOICE(options ...)
573 A structural type which expects to find one of a number of alternative
575 options. An ordered list of types is provided, all of which must
576 support probe. This will pass an argument whose i field gives the index
577 of the first choice that was accepted. The first option takes the value
578 0.
579 As each of the options is interpreted as an alternative, not a
581 sequence, you should use "XPK_SEQUENCE" if a sequence of multiple items
582 should be considered as a single alternative.
583 It is not an error if no choice matches. At that point, the i field
585 will be set to -1.
586 If you require a failure message in this case, set the final choice to
588 be of type "XPK_FAILURE". This will cause an error message to be
589 printed instead.
590 XPK_FAILURE("message string")
592 XPK_TAGGEDCHOICE
594 structural, can probe, emits i.
595 XPK_TAGGEDCHOICE(choice, tag, ...)
597 A structural type similar to "XPK_CHOICE", except that each choice type
599 is followed by an element of type "XPK_TAG" which gives an integer. It
600 is that integer value, rather than the positional index of the choice
601 within the list, which is passed in the i field.
602 XPK_TAG(value)
604 As each of the options is interpreted as an alternative, not a
606 sequence, you should use "XPK_SEQUENCE" if a sequence of multiple items
607 should be considered as a single alternative.
608 XPK_COMMALIST
610 structural, might support probe, emits i.
611 XPK_COMMALIST(pieces ...)
613 A structural type which expects to find one or more repeats of its
615 contained pieces, separated by literal comma (",") characters. This is
616 somewhat similar to "XPK_REPEATED", except that it needs at least one
617 copy, needs commas between its items, but does not require that the
618 first contained piece support probe (the comma itself is sufficient to
619 indicate a repeat).
620 An "XPK_COMMALIST" supports probe if its first contained piece does;
622 i.e. is transparent to probing.
623 XPK_PARENS
625 structural, can probe, emits nothing.
626 XPK_PARENS(pieces ...)
628 A structural type which expects to find a sequence of pieces, all
630 contained in parentheses as "( ... )". This will pass no extra
631 arguments.
632 XPK_ARGS
634 structural, emits nothing.
635 XPK_ARGS(pieces ...)
637 A structural type similar to "XPK_PARENS", except that the parentheses
639 themselves are optional; much like Perl's parsing of calls to known
640 functions.
641 If parentheses are encountered in the input, they will be consumed by
643 this piece and it will behave identically to "XPK_PARENS". If there is
644 no open parenthesis, this piece will behave like "XPK_SEQUENCE" and
645 consume all the pieces inside it, without expecting a closing
646 parenthesis.
647 XPK_BRACKETS
649 structural, can probe, emits nothing.
650 XPK_BRACKETS(pieces ...)
652 A structural type which expects to find a sequence of pieces, all
654 contained in square brackets as "[ ... ]". This will pass no extra
655 arguments.
656 XPK_BRACES
658 structural, can probe, emits nothing.
659 XPK_BRACES(pieces ...)
661 A structural type which expects to find a sequence of pieces, all
663 contained in braces as "{ ... }". This will pass no extra arguments.
664 Note that this is not necessary to use with "XPK_BLOCK" or
666 "XPK_ANONSUB"; those will already consume a set of braces. This is
667 intended for special constrained syntax that should not just accept an
668 arbitrary block.
669 XPK_CHEVRONS
671 structural, can probe, emits nothing.
672 XPK_CHEVRONS(pieces ...)
674 A structural type which expects to find a sequence of pieces, all
676 contained in angle brackets as "< ... >". This will pass no extra
677 arguments.
678 Remember that expressions like "a > b" are valid term expressions, so
680 the contents of this scope shouldn't allow arbitrary expressions or the
681 closing bracket will be ambiguous.
682 XPK_PARENS_OPT, XPK_BRACKETS_OPT, XPK_BRACES_OPT, XPK_CHEVRONS_OPT
684 structural, can probe, emits i.
685 XPK_PARENS_OPT(pieces ...)
687 XPK_BRACKETS_OPT(pieces ...)
688 XPK_BRACES_OPT(pieces ...)
689 XPK_CHEVERONS_OPT(pieces ...)
690 Each of the four contained structure macros above has an optional
692 variant, whose name is suffixed by "_OPT". These pass an argument whose
693 i field is either true or false, indicating whether the scope was
694 found, followed by the values from the scope itself.
695 This is a convenient shortcut to nesting the scope within a
697 "XPK_OPTIONAL" macro.
698 XPK_..._pieces
700 XPK_SEQUENCE_pieces(ptr)
701 XPK_OPTIONAL_pieces(ptr)
702 ...
703 For each of the "XPK_..." macros that takes a variable-length list of
705 pieces, there is a variant whose name ends with "..._pieces", taking a
706 single pointer argument directly. This must point at a "const
707 XSParseKeywordPieceType []" array whose final element is the zero
708 element.
709 Normally hand-written C code of a fixed grammar would be unlikely to
711 use these forms, but they may be useful in dynamically-generated cases.
712
714 Paul Evans <leonerd@leonerd.org.uk>
715perl v5.38.0 2023-08-09 XS::Parse::Keyword(3pm)