Filter::Simple(3pm)
π Filter::Simple(3pm) β Simplified source filtering π
Welcome to the Filter::Simple(3pm) page from the Perl Programmers Reference Guide, bestie π β this is the part where we make source filtering feel less like a boss fight and more like a cute little group project. No cap.
πΈ NAME πΈ
Filter::Simple β Simplified source filtering π
π SYNOPSIS π
# in MyFilter.pm:
package MyFilter;
use Filter::Simple;
FILTER { ... };
# or just:
#
# use Filter::Simple sub { ... };
# in user's code:
use MyFilter;
# this code is filtered
no MyFilter;
# this code is not
π₯ DESCRIPTION π₯
𧨠The Problem π§¨
Source filtering is, like, an immensely powerful feature of recent versions of Perl. It lets you extend the language itself (e.g. the Switch module), simplify the language (e.g. Language::Pythonesque), or completely recast the language (e.g. Lingua::Romana::Perligata). Effectively, it lets you use the full power of Perl as its own, recursively applied, macro language. Itβs giving βlanguage inception,β honestly π«.
The excellent Filter::Util::Call module (by Paul Marquess) provides a usable Perl interface to source filtering, but it is often too powerful and not nearly as simple as it could be. Too much power, not enough chill.
To use the module it is necessary to do the following:
- Download, build, and install the
Filter::Util::Callmodule. (If you have Perl 5.7.1 or later, this is already done for you.) β¨ - Set up a module that does a
use Filter::Util::Call. - Within that module, create an
importsubroutine. - Within the
importsubroutine do a call tofilter_add, passing it either a subroutine reference. - Within the subroutine reference, call
filter_readorfilter_read_exactto βprimeβ$_with source code data from the source file that will βuseβ your module. Check the status value returned to see if any source code was actually read in. - Process the contents of
$_to change the source code in the desired manner. - Return the status value.
- If the act of unimporting your module (via a
no) should cause source code filtering to cease, create anunimportsubroutine, and have it callfilter_del. Make sure that the call tofilter_readorfilter_read_exactin step 5 will not accidentally read past theno. Effectively this limits source code filters to line-by-line operation, unless theimportsubroutine does some fancy pre-pre-parsing of the source code itβs filtering.
For example, here is a minimal source code filter in a module named BANG.pm. It simply converts every occurrence of the sequence BANG\s+BANG to the sequence die 'BANG' if $BANG in any piece of code following a use BANG; statement (until the next no BANG; statement, if any):
package BANG;
use Filter::Util::Call ;
sub import {
filter_add( sub {
my $caller = caller;
my ($status, $no_seen, $data);
while ($status = filter_read()) {
if (/^\s*no\s+$caller\s*;\s*?$/) {
$no_seen=1;
last;
}
$data .= $_;
$_ = "";
}
$_ = $data;
s/BANG\s+BANG/die 'BANG' if \$BANG/g
unless $status < 0;
$_ .= "no $class;\n" if $no_seen;
return 1;
})
}
sub unimport {
filter_del();
}
1 ;
This level of sophistication puts filtering out of the reach of many programmers. π Itβs a lot, bestie. We know.
β¨ A Solution β¨
The Filter::Simple module provides a simplified interface to Filter::Util::Call; one that is sufficient for most common cases. Finally, a vibe check that passes.
Instead of the above process, with Filter::Simple the task of setting up a source code filter is reduced to:
- Download and install the
Filter::Simplemodule. (If you have Perl 5.7.1 or later, this is already done for you.) π«Ά - Set up a module that does a
use Filter::Simpleand then callsFILTER { ... }. - Within the anonymous subroutine or block that is passed to
FILTER, process the contents of$_to change the source code in the desired manner.
In other words, the previous example would become:
package BANG;
use Filter::Simple;
FILTER {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
};
1 ;
Note that the source code is passed as a single string, so any regex that uses ^ or $ to detect line boundaries will need the /m flag. π
π
Disabling or changing no behaviour π
By default, the installed filter only filters up to a line consisting of one of the three standard source βterminatorsβ:
no ModuleName; # optional comment
or:
__END__
or:
__DATA__
but this can be altered by passing a second argument to use Filter::Simple or FILTER (just remember: thereβs no comma after the initial block when you use FILTER). Important little comma note, bestie β do not freelance it.
That second argument may be either a qrβd regular expression (which is then used to match the terminator line), or a defined false value (which indicates that no terminator line should be looked for), or a reference to a hash (in which case the terminator is the value associated with the key 'terminator').
For example, to cause the previous filter to filter only up to a line of the form:
GNAB esu;
you would write:
package BANG;
use Filter::Simple;
FILTER {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
}
qr/^\s*GNAB\s+esu\s*;\s*?$/;
or:
FILTER {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
}
{ terminator => qr/^\s*GNAB\s+esu\s*;\s*?$/ };
and to prevent the filterβs being turned off in any way:
package BANG;
use Filter::Simple;
FILTER {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
}
""; # or: 0
or:
FILTER {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
}
{ terminator => "" };
Note that, no matter what you set the terminator pattern to, the actual terminator itself must be contained on a single source line. Single. Line. Periodt. π
ποΈ All-in-one interface ποΈ
Separating the loading of Filter::Simple:
use Filter::Simple;
from the setting up of the filtering:
FILTER { ... };
is useful because it allows other code (typically parser support code or caching variables) to be defined before the filter is invoked. However, there is often no need for such a separation. Sometimes you just want the combo deal.
In those cases, it is easier to just append the filtering subroutine and any terminator specification directly to the use statement that loads Filter::Simple, like so:
use Filter::Simple sub {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
};
This is exactly the same as:
use Filter::Simple;
BEGIN {
Filter::Simple::FILTER {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
};
}
except that the FILTER subroutine is not exported by Filter::Simple. Subtle but real, bestie.
π― Filtering only specific components of source code π―
One of the problems with a filter like:
use Filter::Simple;
FILTER { s/BANG\s+BANG/die 'BANG' if \$BANG/g };
is that it indiscriminately applies the specified transformation to the entire text of your source program. So something like:
warn 'BANG BANG, YOU'RE DEAD';
BANG BANG;
will become:
warn 'die 'BANG' if $BANG, YOU'RE DEAD';
die 'BANG' if $BANG;
Yeah. That happened. π
It is very common when filtering source to only want to apply the filter to the non-character-string parts of the code, or alternatively to only the character strings.
Filter::Simple supports this type of filtering by automatically exporting the FILTER_ONLY subroutine. π
FILTER_ONLY takes a sequence of specifiers that install separate (and possibly multiple) filters that act on only parts of the source code. For example:
use Filter::Simple;
FILTER_ONLY
code => sub { s/BANG\s+BANG/die 'BANG' if \$BANG/g },
quotelike => sub { s/BANG\s+BANG/CHITTY CHITTY/g };
The code subroutine will only be used to filter parts of the source code that are not quotelikes, POD, or __DATA__. The quotelike subroutine only filters Perl quotelikes (including here documents).
The full list of alternatives is:
codeβ Filters only those sections of the source code that are not quotelikes, POD, or__DATA__.code_no_commentsβ Filters only those sections of the source code that are not quotelikes, POD, comments, or__DATA__.executableβ Filters only those sections of the source code that are not POD or__DATA__.executable_no_commentsβ Filters only those sections of the source code that are not POD, comments, or__DATA__.quotelikeβ Filters only Perl quotelikes (as interpreted by&Text::Balanced::extract_quotelike).stringβ Filters only the string literal parts of a Perl quotelike (i.e. the contents of a string literal, either half of atr///, the second half of ans///).regexβ Filters only the pattern literal parts of a Perl quotelike (i.e. the contents of aqr//or anm//, the first half of ans///).allβ Filters everything. Identical in effect toFILTER.
Except for FILTER_ONLY code => sub {...}, each of the component filters is called repeatedly, once for each component found in the source code. Tiny detail, big energy.
Note that you can also apply two or more of the same type of filter in a single FILTER_ONLY. For example, hereβs a simple macro-preprocessor that is only applied within regexes, with a final debugging pass that prints the resulting source code:
use Regexp::Common;
FILTER_ONLY
regex => sub { s/!\[/[^/g },
regex => sub { s/%d/$RE{num}{int}/g },
regex => sub { s/%f/$RE{num}{real}/g },
all => sub { print if $::DEBUG };
π§Ό Filtering only the code parts of source code π§Ό
Most source code ceases to be grammatically correct when it is broken up into the pieces between string literals and regexes. So the 'code' and 'code_no_comments' component filter behave slightly differently from the other partial filters described in the previous section. Grammar said βnot today,β basically.
Rather than calling the specified processor on each individual piece of code (i.e. on the bits between quotelikes), the 'code...' partial filters operate on the entire source code, but with the quotelike bits (and, in the case of 'code_no_comments', the comments) βblanked outβ.
That is, a 'code...' filter replaces each quoted string, quotelike, regex, POD, and __DATA__ section with a placeholder. The delimiters of this placeholder are the contents of the $; variable at the time the filter is applied (normally "\034"). The remaining four bytes are a unique identifier for the component being replaced. π
This approach makes it, like, so much easier to write code preprocessors without spiraling into anxiety about the form or contents of strings, regexes, etc. π Big slay.
For convenience β and honestly, this is the iconic part β during a 'code...' filtering operation, Filter::Simple hands you a package variable called $Filter::Simple::placeholder that contains a pre-compiled regex. That regex matches any placeholderβ¦ and captures the identifier inside the placeholder. Placeholders can be moved around and re-ordered inside the source code as much as you need. No cap. β¨
Plus, there's a second package variable, @Filter::Simple::components, which holds a list of all the various pieces of $_ β exactly as they were originally split up so placeholders could be inserted. Think of it as the receipts. π§Ύ
Once the filtering has been applied, the original strings, regexes, POD, etc. get re-inserted into the code by replacing each placeholder with the corresponding original component (from @components). Which means β and listen, this is important β @components must be treated with extreme care inside the filter. π
The @components array stores the "back-translations" of each placeholder inserted into $_, plus the interstitial source code that lives between placeholders. So if you go and alter the placeholder backtranslations in @components, they'll be similarly changed when the placeholders get removed from $_ after the filter is complete. Cause and effect, bestie. π¦
For example, this filter here detects concatenated pairs of strings/quotelikes and reverses the order in which they're concatenated:
package DemoRevCat;
use Filter::Simple;
FILTER_ONLY code => sub {
my $ph = $Filter::Simple::placeholder;
s{ ($ph) \s* [.] \s* ($ph) }{ $2.$1 }gx
};
So this code here:
use DemoRevCat;
my $str = "abc" . q(def);
print "$str\n";
would become:
my $str = q(def)."abc";
print "$str\n";
and hence print:
defabc
Obsessed. It literally just flipped the whole thing. π₯
β¨ Using Filter::Simple with an explicit import subroutine β¨
Okay so, Filter::Simple generates a special import subroutine for your module (hit up "How it works" for the deets) β and that would normally replace any import subroutine you might have explicitly declared. Rude, right? π
But good news: Filter::Simple is smart enough to notice your existing import and Do The Right Thing with it. So if you explicitly define an import subroutine in a package that's using Filter::Simple, that import subroutine will still be invoked immediately after any filter you install. π«Ά
The only thing you gotta remember is that the import subroutine has to be declared before the filter is installed. If you use FILTER to install the filter:
package Filter::TurnItUpTo11;
use Filter::Simple;
FILTER { s/(\w+)/\U$1/ };
that'll almost never be a problem. But if you install a filtering subroutine by passing it directly to the use Filter::Simple statement:
package Filter::TurnItUpTo11;
use Filter::Simple sub{ s/(\w+)/\U$1/ };
then you must make sure your import subroutine appears before that use statement. Order matters, bestie. β
πΈ Using Filter::Simple and Exporter together πΈ
Likewise β love a consistent queen β Filter::Simple is also smart enough to Do The Right Thing if you use Exporter:
package Switch;
use base Exporter;
use Filter::Simple;
@EXPORT = qw(switch case);
@EXPORT_OK = qw(given when);
FILTER { $_ = magic_Perl_filter($_) }
Immediately after the filter has been applied to the source, Filter::Simple passes control to Exporter so it can do its magic too. Teamwork makes the dream work. π
And of course, here too, Filter::Simple has to know you're using Exporter before it applies the filter. That's almost never a problem, but if you're nervous about it, you can guarantee things will work correctly by making sure your use base Exporter always precedes your use Filter::Simple. π
π How it works π
The Filter::Simple module exports into the package that calls FILTER (or uses it directly) β like package BANG in the above example β two automagically constructed subroutines: import and unimport. Those two handle all the nasty details so you don't have to. π
In addition, the generated import subroutine passes its own argument list to the filtering subroutine, so the BANG.pm filter could easily be made parametric:
package BANG;
use Filter::Simple;
FILTER {
my ($die_msg, $var_name) = @_;
s/BANG\s+BANG/die '$die_msg' if \${$var_name}/g;
};
# and in some user code:
use BANG "BOOM", "BAM"; # "BANG BANG" becomes: die 'BOOM' if $BAM
The specified filtering subroutine gets called every single time a use BANG is encountered, and it's passed all the source code following that call, up to either the next no BANG; (or whatever terminator you've set) or the end of the source file β whichever occurs first. By default, any no BANG; call must appear by itself on a separate line, or it is ignored. π€ Yes, it's picky. That's the vibe.
π¦ AUTHOR π¦
Damian Conway
π CONTACT π
Filter::Simple is now maintained by the Perl5-Porters. Please submit bug via the perlbug tool that comes with your perl. For usage instructions, read perldoc perlbug or possibly man perlbug. For mostly anything else, please contact <perl5-porters@perl.org>.
Maintainer of the CPAN release is Steffen Mueller <smueller@cpan.org>. Contact him with technical difficulties with respect to the packaging of the CPAN module.
Praise of the module, flowers, and presents still go to the author, Damian Conway <damian@conway.org>. π· (As they should, honestly.)
π COPYRIGHT AND LICENSE π
Copyright (c) 2000-2014, Damian Conway. All Rights Reserved.
This module is free software. It may be used, redistributed
and/or modified under the same terms as Perl itself.
And that's the whole page, bestie, you made it all the way to the end ππ This was perl v5.42.3, dated 2026-11-03, and it's Filter::Simple(3pm) β go forth and preprocess the absolute heck out of some source code. Slay. π¦β¨
π¦ where this page comes from
- alpine 3.24: perl-doc 5.42.3-r0 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms