At YAPC::NA 2011, the hotel made the understandable mistake of directing attendees to "The PERL Foundation" event. As you might expect someone corrected the sign by prepending ucfirst lc .

Any self-respecting Perl hacker should be able to devise several more creative (if less straightforward) ways to correct such a mishap.

While JAPHs and obfuscations are fun, why not correct the problem at the root? What if it were impossible to write PERL by accident? Enter Acme::PERL::Autocorrect, an extension to the Perl optimizer which automatically corrects PERL to Perl in literal strings in Perl source code.

The initial version only fixed strings containing PERL . The second version improves that to detect PERL as a substring. That improvement was more difficult than it might seem. My first approach made the tests themselves fail:

# Failed test 'use Acme::Perl::Autocorrect;' # at t/autocorrect.t line 7. # Tried to use 'Acme::Perl::Autocorrect'. # Error: Can't locate Acme/Perl/Autocorrect.pm in @INC...

... for the test line:

BEGIN { use_ok( 'Acme::PERL::Autocorrect' ) }

... because the string in that statement gets rewritten as part of the optimization process. The naï approach is to use a negative-width lookahead regular expression to find PERL:: and exclude that from the rewriting, but that doesn't work. By the time the custom operator override gets to this string, Perl's optree contains instead Acme/PERL/Autocorrect.pm .

You may have to install a development version of optimizer to make this work, but work it does—with pure Perl. You need a decent understanding of the Perl optree to write an optimizer stage, but even this silly Acme:: module demonstrates that such things are possible.