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.
