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".