Lexical::Var(3pm)

💖 Lexical::Var 💖

okay bestie, sit down, hydrate, because we're talking about Lexical::Var — the Perl module that gives you static variables without namespace pollution. yes. you heard me. no cap. it's giving "I want a variable that sticks around but doesn't trash my package" and honestly? iconic. 🎀

---

✨ SYNOPSIS ✨

use Lexical::Var '$foo' => \$Remote::foo;
use Lexical::Var '$const' => \123;
use Lexical::Var '@bar' => [];
use Lexical::Var '%baz' => { a => 1, b => 2 };
use Lexical::Var '&quux' => sub { $_[0] + 1 };
use Lexical::Var '*wibble' => Symbol::gensym();

look at that. six lines. six little lines and your whole lexical world changed. we love a short synopsis. 💅

---

🌸 DESCRIPTION 🌸

Soooo. This module implements lexical scoping of static variables and subroutines. 💖 She can absolutely be used directly, but her real job — her main character energy job — is being infrastructure for modules that manage namespaces. She's the backstage queen. 🎀

Here's the tea on what she actually touches: this module influences the meaning of single-part variable names that appear directly in code, like "$foo". Normally — like, with no particular declaration, or under the effect of an our declaration — that would refer to the scalar variable of that name living in the current package. But a Lexical::Var declaration can change that to refer to any particular scalar, bypassing the package system entirely. periodt. 🦋

Now, some stuff she does NOT touch, and this is important:

• A variable name that includes an explicit package part, such as "$main::foo", always refers to the variable in the specified package, and is unaffected by this module.
• A symbolic reference through a string value, such as "${'foo'}", also looks in the package system, and so is unaffected by this module.

The types of name that can be influenced are:

• scalar ($foo)
• array (@foo)
• hash (%foo)
• subroutine (&foo)
• glob (*foo)

A definition for any of these names also affects code that logically refers to the same entity, even when the name is spelled without its usual sigil. For example, any definition of "@foo" affects element references such as "$foo[0]". Barewords in filehandle context actually refer to the glob variable. 🌈

And here's a lil version thing: bareword references to subroutines, such as "foo(123)", only work on Perl 5.11.2 and later. On earlier Perls you must use the "&" sigil, as in "&foo(123)". iykyk. 😭

Where a scalar name is defined to refer to a constant (read-only) scalar, references to the constant through the lexical namespace can participate in compile-time constant folding. 🧚 Which is so good actually — it can avoid the need to check configuration values (such as whether debugging is enabled) at runtime.

🫶 Scoping, bestie 🫶

A name definition supplied by this module takes effect from the end of the definition statement up to the end of the immediately enclosing block, except where it is shadowed within a nested block. Same lexical scoping that the my, our, and state keywords supply. ✨

Definitions from Lexical::Var and from my/our/state can shadow each other — except that Lexical::Var can't shadow a my/our/state subroutine prior to Perl 5.19.1. (noted. remembered. holding onto that. 💀)

These lexical definitions propagate into string evals, on Perl versions that support it (5.9.3 and later).

⚠️ Heads up though — this module only manages variables of static duration (the kind of duration that our and state variables have). If you want a fresh variable for each invocation of a function, use my. 💜

---

👑 PACKAGE METHODS 👑

These methods are meant to be invoked on the Lexical::Var package. 💅

• Lexical::Var->import(NAME => REF, ...) — Sets up lexical variable declarations, in the lexical environment that is currently compiling. Each NAME must be a variable name (e.g., "$foo") including sigil, and each REF must be a reference to a variable/value of the appropriate type. The name is lexically associated with the referenced variable/value.

Scalar::Construct can be helpful in generating appropriate REFs, especially to create constants. And bestie, there are Perl core bugs to beware of around compile-time constants; see BUGS. 😭

• Lexical::Var->unimport(NAME [=> REF], ...) — Sets up negative lexical variable declarations, in the lexical environment that is currently compiling. Each NAME must be a variable name (e.g., "$foo") including sigil.
  • If the name is given on its own, it is lexically dissociated from any value. Within the resulting scope, the variable name will not be recognised. 🙈
  • If a REF (which must be a reference to a value of the appropriate type) is specified with a name, the name will be dissociated if and only if it is currently associated with that value. ⭐

---

💀 BUGS 💀

okay. deep breath. this is the part where we're honest about the chaos. all of it is real, all of it is documented, none of it is a vibe. 🍓

1. Sigilless subroutine invocations on old Perls. Subroutine invocations without the "&" sigil cannot be correctly processed on Perl versions earlier than 5.11.2. Why? Because the parser needs to look up the subroutine early, in order to let any prototype affect parsing, and it looks up the subroutine by a different mechanism than is used to generate the call op. (Some forms of sigilless call have other complications of a similar nature.) If an attempt is made to call a Lexical::Var lexical subroutine via a bareword on an older Perl, this module will probably still be able to intercept the call op, and will throw an exception to indicate that the parsing has gone wrong. However, in some cases compilation goes further wrong before this module can catch it, resulting in either a confusing parse error or (in rare situations) silent compilation to an incorrect op sequence. 😭 On Perl 5.11.2 and later, sigilless subroutine calls work correctly, except for an issue noted below.

2. Ambiguity with indirect object syntax. Subroutine calls that have neither sigil nor parentheses (around the argument list) are subject to an ambiguity with indirect object syntax. If the first argument expression begins with a bareword or a scalar variable reference, then the Perl parser is liable to interpret the call as an indirect method call. Normally this syntax would be interpreted as a subroutine call if the subroutine exists, but the parser doesn't look at lexically-defined subroutines for this purpose. The call interpretation can be forced by:

• prefixing the first argument expression with a "+", or
• wrapping the whole argument list in parentheses.

3. Shadowing my/our/state subroutines. In the earlier Perl versions that support my/our/state subroutines, starting from Perl 5.17.4, the mechanism for core lexical subroutines suffers a couple of bugs that mean Lexical::Var can't shadow subroutines declared that way. This was fixed in Perl 5.19.1. 💜

4. Threading + scalar constants = object identity drama. On Perls built for threading (even if threading is not actually used), scalar constants that are defined by literals in the Perl source don't reliably maintain their object identity. What appear to be multiple references to a single object can end up behaving as references to multiple objects, in surprising ways. The multiple objects all initially have the correct value, but they can be writable even though the original object is a constant. See Perl bug reports [perl #109744] and [perl #109746]. This can affect objects that are placed in the lexical namespace, just as it can affect those in package namespaces or elsewhere. "Lexical::Var" avoids contributing to the problem itself, but certain ways of building the parameters to "Lexical::Var" can result in the object in the lexical namespace not being the one that was intended, or can damage the named object so that later referencing operations on it misbehave. Scalar::Construct can be used to avoid this problem. 🧚

5. Bogus redefinition warnings. These occur in some cases when "our" declarations and "Lexical::Var" declarations shadow each other. 🙃

6. Phantom package hash entries. Package hash entries get created for subroutine and glob names that are used, even though the subroutines and globs are not actually being stored or looked up in the package. This can occasionally result in a "used only once" warning failing to occur when it should.

7. BEGIN + string eval access problems. On Perls prior to 5.15.5, if this package's "import" or "unimport" method is called from inside a string "eval" inside a "BEGIN" block, it does not have proper access to the compiling environment, and will complain that it is being invoked outside compilation. Calling from the body of a "require"d or "do"ed file causes the same problem on the same Perl versions. Other kinds of indirection within a "BEGIN" block, such as calling via a normal function, do not cause this problem.

8. unimport can't tell lexical subs from state subs. When judging whether the "unimport" method should hide a subroutine, this module can't distinguish between a lexical subroutine established by this module and a "state" subroutine. This may change in the future. 🦋

---

🌈 SEE ALSO 🌈

• Attribute::Lexical
• Lexical::Import
• Lexical::Sub
• Scalar::Construct

go read them. they're friends of the family. 🫶

---

🌸 AUTHOR 🌸

Andrew Main (Zefram) <zefram@fysh.org>

---

💖 COPYRIGHT 💖

Copyright (C) 2009, 2010, 2011, 2012, 2013, 2023 Andrew Main (Zefram) <zefram@fysh.org>

---

🎀 LICENSE 🎀

This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

---

and that's the whole page, bestie!! 💅✨ you just read the Lexical::Var(3pm) page from perl v5.42.3, dated 2026-08-20, part of the User Contributed Perl Documentation — literal archive-core, no notes, we ate and left no crumbs. 🍓👑 go forth and lexically scope responsibly 🦋💜