Global Variables These variables are global to an entire process. They are shared between all interpreters and all threads in a process. Any variables not documented here may be changed or removed without notice, so don't use them! If you feel you really do need to use an unlisted variable, first send email to perl5-porters@perl.org. It may be that someone there will point out a way to accomplish what you need without using an internal variable. But if not, you should get a go-ahead to document and then use the variable.
Array, indexed by opcode, of functions that will be called for the "check" phase of optree building during compilation of Perl code. For most (but not all) types of op, once the op has been initially built and populated with child ops it will be filtered through the check function referenced by the appropriate element of this array. The new op is passed in as the sole argument to the check function, and the check function returns the completed op. The check function may (as the name suggests) check the op for validity and signal errors. It may also initialise or modify parts of the ops, or perform more radical surgery such as adding or removing child ops, or even throw the op away and return a different op in its place.
This array of function pointers is a convenient place to hook into the compilation process. An XS module can put its own custom check function in place of any of the standard ones, to influence the compilation of a particular type of op. However, a custom check function must never fully replace a standard check function (or even a custom check function from another module). A module modifying checking must instead wrap the preexisting check function. A custom check function must be selective about when to apply its custom behaviour. In the usual case where it decides not to do anything special with an op, it must chain the preexisting op function. Check functions are thus linked in a chain, with the core's base checker at the end.
For thread safety, modules should not write directly to this array. Instead, use the function "wrap_op_checker".
A value that indicates the current Perl interpreter's phase. Possible values include PERL_PHASE_CONSTRUCT, PERL_PHASE_START, PERL_PHASE_CHECK, PERL_PHASE_INIT, PERL_PHASE_RUN, PERL_PHASE_END, and PERL_PHASE_DESTRUCT.
For example, the following determines whether the interpreter is in global destruction:
if (PL_phase == PERL_PHASE_DESTRUCT) {
// we are in global destruction
}PL_phase was introduced in Perl 5.14; in prior perls you can use PL_dirty (boolean) to determine whether the interpreter is in global destruction. (Use of PL_dirty is discouraged since 5.14.)
Function pointer, pointing at a function used to handle extended keywords. The function should be declared as
int keyword_plugin_function(pTHX_
char *keyword_ptr, STRLEN keyword_len,
OP **op_ptr)The function is called from the tokeniser, whenever a possible keyword is seen. keyword_ptr points at the word in the parser's input buffer, and keyword_len gives its length; it is not null-terminated. The function is expected to examine the word, and possibly other state such as %^H, to decide whether it wants to handle it as an extended keyword. If it does not, the function should return KEYWORD_PLUGIN_DECLINE, and the normal parser process will continue.
If the function wants to handle the keyword, it first must parse anything following the keyword that is part of the syntax introduced by the keyword. See "Lexer interface" for details.
When a keyword is being handled, the plugin function must build a tree of OP structures, representing the code that was parsed. The root of the tree must be stored in *op_ptr. The function then returns a constant indicating the syntactic role of the construct that it has parsed: KEYWORD_PLUGIN_STMT if it is a complete statement, or KEYWORD_PLUGIN_EXPR if it is an expression. Note that a statement construct cannot be used inside an expression (except via do BLOCK and similar), and an expression is not a complete statement (it requires at least a terminating semicolon).
When a keyword is handled, the plugin function may also have (compile-time) side effects. It may modify %^H, define functions, and so on. Typically, if side effects are the main purpose of a handler, it does not wish to generate any ops to be included in the normal compilation. In this case it is still required to supply an op tree, but it suffices to generate a single null op.
That's how the *PL_keyword_plugin function needs to behave overall. Conventionally, however, one does not completely replace the existing handler function. Instead, take a copy of PL_keyword_plugin before assigning your own function pointer to it. Your handler function should look for keywords that it is interested in and handle those. Where it is not interested, it should call the saved plugin function, passing on the arguments it received. Thus PL_keyword_plugin actually points at a chain of handler functions, all of which have an opportunity to handle keywords, and only the last function in the chain (built into the Perl core) will normally return KEYWORD_PLUGIN_DECLINE.
For thread safety, modules should not set this variable directly. Instead, use the function "wrap_keyword_plugin".
NOTE: This API exists entirely for the purpose of making the CPAN module XS::Parse::Infix work. It is not expected that additional modules will make use of it; rather, that they should use XS::Parse::Infix to provide parsing of new infix operators.
Function pointer, pointing at a function used to handle extended infix operators. The function should be declared as
int infix_plugin_function(pTHX_
char *opname, STRLEN oplen,
struct Perl_custom_infix **infix_ptr)The function is called from the tokenizer whenever a possible infix operator is seen. opname points to the operator name in the parser's input buffer, and oplen gives the maximum number of bytes of it that should be consumed; it is not null-terminated. The function is expected to examine the operator name and possibly other state such as %^H, to determine whether it wants to handle the operator name.
As compared to the single stage of PL_keyword_plugin, parsing of additional infix operators occurs in three separate stages. This is because of the more complex interactions it has with the parser, to ensure that operator precedence rules work correctly. These stages are co-ordinated by the use of an additional information structure.
If the function wants to handle the infix operator, it must set the variable pointed to by infix_ptr to the address of a structure that provides this additional information about the subsequent parsing stages. If it does not, it should make a call to the next function in the chain.
This structure has the following definition:
struct Perl_custom_infix {
enum Perl_custom_infix_precedence prec;
void (*parse)(pTHX_ SV **opdata,
struct Perl_custom_infix *);
OP *(*build_op)(pTHX_ SV **opdata, OP *lhs, OP *rhs,
struct Perl_custom_infix *);
};The function must then return an integer giving the number of bytes consumed by the name of this operator. In the case of an operator whose name is composed of identifier characters, this must be equal to oplen. In the case of an operator named by non-identifier characters, this is permitted to be shorter than oplen, and any additional characters after it will not be claimed by the infix operator but instead will be consumed by the tokenizer and parser as normal.
If the optional parse function is provided, it is called immediately by the parser to let the operator's definition consume any additional syntax from the source code. This should not be used for normal operand parsing, but it may be useful when implementing things like parametric operators or meta-operators that consume more syntax themselves. This function may use the variable pointed to by opdata to provide an SV containing additional data to be passed into the build_op function later on.
The information structure gives the operator precedence level in the prec field. This is used to tell the parser how much of the surrounding syntax before and after should be considered as operands to the operator.
The tokenizer and parser will then continue to operate as normal until enough additional input has been parsed to form both the left- and right-hand side operands to the operator, according to the precedence level. At this point the build_op function is called, being passed the left- and right-hand operands as optree fragments. It is expected to combine them into the resulting optree fragment, which it should return.
After the build_op function has returned, if the variable pointed to by opdata was set to a non-NULL value, it will then be destroyed by calling SvREFCNT_dec().
For thread safety, modules should not set this variable directly. Instead, use the function "wrap_infix_plugin".
However, that all said, the introductory note above still applies. This variable is provided in core perl only for the benefit of the XS::Parse::Infix module. That module acts as a central registry for infix operators, automatically handling things like deparse support and discovery/reflection, and these abilities only work because it knows all the registered operators. Other modules should not use this interpreter variable directly to implement them because then those central features would no longer work properly.
Furthermore, it is likely that this (experimental) API will be replaced in a future Perl version by a more complete API that fully implements the central registry and other semantics currently provided by XS::Parse::Infix, once the module has had sufficient experimental testing time. This current mechanism exists only as an interim measure to get to that stage.