Originally published at Perl Weekly 761

Hi there!

Do you use WhatsApp? There is now a WhatsApp group for Perl. Join us!

Thanks to Mikko Koivunalho we now have a graph on the MetaCPAN stats page.

Perl-wise it was a rather weak week: we don't have many articles. On the other hand we are back with a new live online event where we are going to work on one or more CPAN modules. I hope this will encourage more of you to start contributing to open source projects in Perl and maybe also to write articles about your journey. Register here! If the scheduled time-slot is not good for you, come to our WhatsApp group and let's discuss it!

Enjoy your week!

--
Your editor: Gabor Szabo.

Articles

ANN: CPAN::MetaCurator V 1.08, Perl.Wiki V 1.40 etc

Treating GitHub Copilot as a Contributor

Dave Cross just posted this article explaining how to use Github co-pilot as a contributor to your project. We will give it a try next meeting, but you can already try it yourself on one of the TODO items in our list.

Web

Perl/Plack Middleware for Emulating An Apache HTTP Server

Keith released a couple of new Plack middleware modules that he uses as a test web server for pages that will ultimately be under Apache httpd.

Websockets in Catalyst

A detailed example with explanation and use-case.

The Weekly Challenge

The Weekly Challenge by Mohammad Sajid Anwar will help you step out of your comfort-zone. You can even win prize money of $50 by participating in the weekly challenge. We pick one champion at the end of the month from among all of the contributors during the month, thanks to the sponsor Lance Wicks.

The Weekly Challenge - 362

Welcome to a new week with a couple of fun tasks "Echo Chamber" and "Spellbound Sorting". If you are new to the weekly challenge then why not join us and have fun every week. For more information, please read the FAQ.

RECAP - The Weekly Challenge - 361

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Zeckendorf Representation" and "Find Celebrity" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

TWC361

The blog post presents clear and idiomatic Perl solutions for both the Zeckendorf representation and the celebrity problem, showcasing practical logic and efficient algorithmic style. The code is easy to follow and well-structured, making it a great example of solving weekly challenge tasks with solid Perl techniques.

Celebrity Representation

The post showcases a clean and thoughtful Raku solution to computing Zeckendorf representations, demonstrating idiomatic use of sequences and recursion in the language. It's both well-structured and easy to follow, making it a valuable reference for Raku practitioners tackling algorithmic challenges.

numbers

The write-up presents clear and well-structured Raku solutions for both the Zeckendorf sequence and the celebrity problem, with straightforward logic that's easy to follow and learn from. The use of idiomatic Raku constructs and explanatory comments makes the post a solid reference for anyone tackling similar challenges.

Perl Weekly Challenge 361

The post delivers clear and practical Perl implementations for both the Zeckendorf representation and the celebrity detection problems, with complete working scripts and illustrative example outputs. Its well‑organised explanations and real usage examples make it an excellent reference for Perl developers tackling these classic algorithmic tasks.

Was Fibonacci ever a Celebrity?

The post offers solid, well-commented Perl implementations for both TWC361 tasks, clearly expressing the logic behind Zeckendorf decomposition and celebrity detection. The structured approach and readable code make it a valuable example for anyone exploring algorithmic solutions in Perl.

Where Everybody Knows Your Name

The write-up delivers clear and well-structured multi-language solutions for both the Zeckendorf representation and the celebrity detection tasks, with thoughtful explanations of the greedy algorithm and candidate evaluation. The step-by-step approach and readable Perl, Raku, Python, and Elixir code make the post a practical and educational resource for anyone exploring these classic algorithmic problems.

Zeckendorf, the celebrity

The Challenge 361 post clearly states the two tasks - computing the Zeckendorf representation of a number and finding a celebrity in a matrix, along with illustrative examples that make the problem definitions easy to grasp. Its structured presentation of inputs and expected outputs helps readers understand the algorithmic goals before diving into solutions, making it a solid reference for anyone exploring these classic programming challenges.

Zeckendorf Representation

The write-up presents a memory-efficient and well-explained Perl implementation for computing the Zeckendorf representation, cleverly using only two Fibonacci values at a time and clear test examples to illustrate the logic. Its structured presentation and readable code make it a helpful reference for anyone interested in elegant algorithmic Perl solutions.

Find Celebrity

The celebrity finder solution delivers a clear and self-contained Perl implementation that uses readable grep-based checks to identify the celebrity by row and column conditions, backed by several solid test cases illustrating correctness. Its straightforward logic and minimal reliance on external modules make it both accessible and practical for Perl programmers exploring matrix-based algorithms.

The Weekly Challenge #361

The Perl solutions for the challenge combine clear logic with well-commented, idiomatic code that makes both the Zeckendorf representation and celebrity detection easy to follow. The step-by-step explanations and practical test cases offer a solid, educational reference for Perl programmers engaging with classic algorithmic tasks.

Celebrity Zeckendorf

The post offers a clear, language-agnostic walk through both challenge tasks, computing the Zeckendorf representation and finding a celebrity in a matrix, with working code in several languages and readable explanations of the greedy Fibonacci strategy and set-based filtering. Its inclusion of multiple idiomatic implementations makes it a practical and educational read for programmers exploring these classic algorithmic problems.

Representing a celebrity

The post delivers clear, well‑structured Python (with Perl) implementations for both the Zeckendorf representation and celebrity detection tasks, showcasing thoughtful logic and solid error handling. The explanations and example inputs/outputs make the solutions easy to understand and follow, making it a useful resource for anyone practicing these classic algorithmic problems.

Weekly collections

NICEPERL's lists

Great CPAN modules released last week;
MetaCPAN weekly report.

Events

Perl Maven online: Code-reading and Open Source contribution

March 3, 2026

Paris.pm monthly meeting

March 11, 2026

German Perl/Raku Workshop 2026 in Berlin

March 16-18, 2026

Perl Toolchain Summit 2026

April 23-26, 2026

The Perl and Raku Conference 2026

June 26-29, 2026, Greenville, SC, USA

You joined the Perl Weekly to get weekly e-mails about the Perl programming language and related topics.

Want to see more? See the archives of all the issues.

Not yet subscribed to the newsletter? Join us free of charge!

(C) Copyright Gabor Szabo
The articles are copyright the respective authors.

Beautiful Perl series

This post is part of the beautiful Perl features series.
See the introduction post for general explanations about the series.

The last two posts about lexical scoping and dynamic scoping addressed deep subjects and therefore were very long; for this time, we'll discuss trailing commas, a much lighter subject ... that nevertheless deserves detailed comments!

Trailing commas, basic principle

Programming languages that support trailing commas are able to parse a list like

(1, 2, 3, 5, 8,)

without generating an error. In other words, it is legal to put a comma after the last item in the list; that comma is a no-op, so the list above is equivalent to (1, 2, 3, 5, 8). Of course the trailing comma is optional, not mandatory.

When it appears on a single line, like in that example, the trailing comma seems ridiculous; but the interest is when the list is written on several lines:

my @fruits = (
              "apples",
              "oranges",
              "bananas",
             );

Here the trailing comma facilitates later changes to the code, should these become necessary. In this example if we want to comment out bananas, or to switch the order of the fruits, we can operate on single lines without having to care about which fruit comes last.

This feature is a transposition of a principle already familiar in all languages with blocks, namely the fact that the last statement in a block can indifferently have a semicolon or not:

if ($is_simple) {do_simple_stuff()} # no semicolon
else            {initialize();
                 process();
                 cleanup();         # with semicolon
                }

Other arguments are commonly invoked in favor of trailing commas, like the facts that diffs in version control systems are cleaner, or that it is easier to generate code programmatically. Going into such arguments would take too much space here, but discussions on the matter can easily be found on the Internet.

On the other hand, let us mention that some people object to trailing commas, arguing that enumeration sentences in natural language never end with a comma, but rather with a full stop or another punctuation sign that marks the end of the list. Evidently this is true, but a sentence in natural language, once emitted, is not rewritten, while in programming languages rewriting is quite frequent - for this usage trailing commas are interesting in programming.

History and comparison with other languages

Long ago the venerable ANSI C language already accepted trailing commas in array initializers; the same thing for enums was added in C99. Both features propagated into languages of C heritage, like C++, Java, PHP, etc., and of course Perl. But Perl went further: since the beginning (version 1.0 in 1987), Perl supported trailing commas in all kinds of lists, including parameters to subroutines, assignments to lists of variables, or more recently in subroutine signatures:

my ($first,
    $second,
    @others,
   ) = @ARGV;

draw_diagram(Perl   => 1987,
             Python => 1991,
             Java   => 1995,
             );

sub transfer_content($source, 
                     $destination,
                     %options,
                    ) { ... }

I strongly suspect that this early design decision in Perl had an influence on the later conception of other programming languages, although I couldn't find any evidence to prove it - influences are rarely documented in design documents! Here is a historical picture:

• Python had trailing commas since the beginning (1991), but with some peculiarities that will be discussed below;
• Java accepted trailing commas since the beginning (1995), but only in array initializers and enums, like in C; a request to extend this to other lists was formulated in 2006 but was ignored;
• JavaScript accepted trailing commas in array literals since the beginning (1995); later support for allowing them in object literals was added in ES5 (2009) and also for function definitions and calls in JS 2017. The global picture is well documented in the MDN documentation, and lots of examples are shown in a blog by logrocket. However JavaScript has a strange edge case with array literals, which will be discussed below. Furthermore, beware that JSON, not a programming language but a data interchange format closely related to JavaScript, does not support trailing commas;
• C++ inherited from C a restricted use of trailing commas; a recent proposal (2025) to extend the support to more general use cases is still pending;
• Kotlin added general support for trailing commas in version 1.4.0 (2020);
• PHP extended its support for trailing commas in version 8.0 (2020).

So nowadays there seems to be a clear tendency towards adoption of trailing commas in many major languages, and some languages are still working on extending their support in this area.

Edge cases in other languages

Trailing commas in Perl are true no-ops, in every context. Furthermore, intermediate commas in a list, or several commas at the end, are also allowed, without any semantic consequence; this is not very useful, but has the nice property of requiring absolutely no reasoning from the programmer, for example when large chunks of code are reshuffled in the course of a refactoring operation. By contrast, Python and JavaScript have edge cases, as shown in the rest of this chapter.

Python : the tuple exception

In Python the array expression [1, 2, 3,] is legal, but expressions [1, 2, , 3,] or [1, 2, 3,,] are not: in other words, intermediate commas or multiple trailing commas are not allowed. This is just a minor syntactic restriction, not very annoying.

A more severe peculiarity is the "tuple exception", namely the fact that these two expressions are semantically different:

(123)    # single value
(123,)   # tuple with one member

Actually, the syntax with the trailing comma is the only way to write a singleton tuple. Another situation, related to the first, comes from the fact that tuples in some contexts are written without parenthesis; so these two lines are again semantically different:

x = 123  # assign a scalar value to x
x = 123, # assign a singleton tuple to x

whereas with tuples of more than one element, the trailing comma is a true no-op:

x = 1, 2, 3  # assign a triple to x
x = 1, 2, 3, # same thing

Furthermore, in singleton lists (as opposed to singleton tuples), trailing commas are also a no-op:

y = [1]      # assign a singleton list to y
y = [1,]     # same thing

So when trailing commas appear in Python code, some thought is required to get the proper meaning.

JavaScript: the sparse array exception

Now let us consider trailing commas in JavaScript. Within object literals, they are true no-ops:

{x:1, y:2, }   // equivalent to {x:1, y:2}

but like in Python, it is not possible to write intermediate commas or several trailing commas

{x:1, , y:2, } // Uncaught SyntaxError: Unexpected token ','
{x:1, y:2,, }  // idem

The situation with array literals is quite different: there the syntax admits intermediate commas and several trailing commas, but semantically they occupy slots in the array:

[1, , 2, 3,,,] // [ 1, <1 empty item>, 2, 3, <2 empty items> ]

This example is an array of length 6, but with only 3 occupied slots - something that is called a sparse array in JavaScript parlance. Empty slots in the array are not equivalent to undefined; their meaning depends on the operation applied to the array, as explained in this MDN document.

Like in Python, when trailing commas appear in JavaScript code, some thought is required to get the proper meaning.

Wrapping up

Trailing commas are a relatively minor topic, but it is interesting to observe that Perl since its initial design made wise decisions with this feature. Trailing commas are treated consistently in all Perl programming constructs, without any surprises for the programmer. In comparison to C, Perl widened the contexts where trailing commas were admitted, and this was probably an inspiration to many other programming languages. Isn't that beautiful ?

About the cover picture

The cover picture shows the initial bars of fugue BWV885 from Johann Sebastian Bach, in a manuscript which is not from the hand of the composer but was transmitted to us by his son-in-law Johann Christoph Altnickol. The theme of that fugue is very recognizable as it repeats the same note seven times before moving to something else - so it reminded me of repeated commas! But this is just a wink; in reality, the illustration is absolutely not relevant with respect to the main theme of this article, because the repetition of notes in the theme is by no means a no-op - on the contrary, it is a strong reinforcement. On a violin a similar effect could be obtained by performing a crescendo on a long note; but on a harpsichord or an organ a note cannot be changed after the initial attack - so repetition is another device to convey the idea of reinforcement.

For some time, we’ve talked about GitHub Copilot as if it were a clever autocomplete engine.

It isn’t.

Or rather, that’s not all it is.

The interesting thing — the thing that genuinely changes how you work — is that you can assign GitHub issues to Copilot.

And it behaves like a contributor.

Over the past day, I’ve been doing exactly that on my new CPAN module, WebServer::DirIndex. I’ve opened issues, assigned them to Copilot, and watched a steady stream of pull requests land. Ten issues closed in about a day, each one implemented via a Copilot-generated PR, reviewed and merged like any other contribution.

That still feels faintly futuristic. But it’s not “vibe coding”. It’s surprisingly structured.

Let me explain how it works.

It Starts With a Proper Issue

This workflow depends on discipline. You don’t type “please refactor this” into a chat window. You create a proper GitHub issue. The sort you would assign to another human maintainer. For example, here are some of the recent issues Copilot handled in WebServer::DirIndex:

• Add CPAN scaffolding
• Update the classes to use Feature::Compat::Class
• Replace DirHandle
• Add WebServer::DirIndex::File
• Move render() method
• Use :reader attribute where useful
• Remove dependency on Plack

Each one was a focused, bounded piece of work. Each one had clear expectations.

The key is this: Copilot works best when you behave like a maintainer, not a magician.

You describe the change precisely. You state constraints. You mention compatibility requirements. You indicate whether tests need to be updated.

Then you assign the issue to Copilot.

And wait.

The Pull Request Arrives

After a few minutes — sometimes ten, sometimes less — Copilot creates a branch and opens a pull request.

The PR contains:

• Code changes
• Updated or new tests
• A descriptive PR message

And because it’s a real PR, your CI runs automatically. The code is evaluated in the same way as any other contribution.

This is already a major improvement over editor-based prompting. The work is isolated, reviewable, and properly versioned.

But the most interesting part is what happens in the background.

Watching Copilot Think

If you visit the Agents tab in the repository, you can see Copilot reasoning through the issue.

It reads like a junior developer narrating their approach:

• Interpreting the problem
• Identifying the relevant files
• Planning changes
• Considering test updates
• Running validation steps

And you can interrupt it.

If it starts drifting toward unnecessary abstraction or broad refactoring, you can comment and steer it:

• Please don’t change the public API.
• Avoid experimental Perl features.
• This must remain compatible with Perl 5.40.

It responds. It adjusts course.

This ability to intervene mid-flight is one of the most useful aspects of the system. You are not passively accepting generated code — you’re supervising it.

Teaching Copilot About Your Project

Out of the box, Copilot doesn’t really know how your repository works. It sees code, but it doesn’t know policy.

That’s where repository-level configuration becomes useful.

1. Custom Repository Instructions

GitHub allows you to provide a .github/copilot-instructions.md file that gives Copilot repository-specific guidance. The documentation for this lives here:

• Adding repository custom instructions for GitHub Copilot

When GitHub offers to generate this file for you, say yes.

Then customise it properly.

In a CPAN module, I tend to include:

• Minimum supported Perl version
• Whether Feature::Compat::Class is preferred
• Whether experimental features are forbidden
• CPAN layout expectations (lib/, t/, etc.)
• Test conventions (Test::More, no stray diagnostics)
• A strong preference for not breaking the public API

Without this file, Copilot guesses.

With this file, Copilot aligns itself with your house style.

That difference is impressive.

2. Customising the Copilot Development Environment

There’s another piece that many people miss: Copilot can run a special workflow event called copilot_agent_setup.

You can define a workflow that prepares the environment Copilot works in. GitHub documents this here:

• Customizing the development environment for GitHub Copilot coding agent

In my Perl projects, I use this standard setup:

name: Copilot Setup Steps

on: copilot_agent_setup

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    permissions:
      contents: read
  steps:
    - name: Check out repository
      uses: actions/checkout@v4

    - name: Set up Perl 5.40
      uses: shogo82148/actions-setup-perl@v1
      with:
        perl-version: '5.40'

    - name: Install dependencies
      run: cpanm --installdeps --with-develop --notest .

(Obviously, that was originally written for me by Copilot!)

This does two important things.

Firstly, it ensures Copilot is working with the correct Perl version.

Secondly, it installs the distribution dependencies, meaning Copilot can reason in a context that actually resembles my real development environment.

Without this workflow, Copilot operates in a kind of generic space.

With it, Copilot behaves like a contributor who has actually checked out your code and run cpanm.

That’s a useful difference.

Reviewing the Work

This is the part where it’s important not to get starry-eyed.

I still review the PR carefully.

I still check:

• Has it changed behaviour unintentionally?
• Has it introduced unnecessary abstraction?
• Are the tests meaningful?
• Has it expanded scope beyond the issue?

I check out the branch and run the tests. Exactly as I would with a PR from a human co-worker.

You can request changes and reassign the PR to Copilot. It will revise its branch.

The loop is fast. Faster than traditional asynchronous code review.

But the responsibility is unchanged. You are still the maintainer.

Why This Feels Different

What’s happening here isn’t just “AI writing code”. It’s AI integrated into the contribution workflow:

• Issues
• Structured reasoning
• Pull requests
• CI
• Review cycles

That architecture matters.

It means you can use Copilot in a controlled, auditable way.

In my experience with WebServer::DirIndex, this model works particularly well for:

• Mechanical refactors
• Adding attributes (e.g. :reader where appropriate)
• Removing dependencies
• Moving methods cleanly
• Adding new internal classes

It is less strong when the issue itself is vague or architectural. Copilot cannot infer the intent you didn’t articulate.

But given a clear issue, it’s remarkably capable — even with modern Perl using tools like Feature::Compat::Class.

A Small but Important Point for the Perl Community

I’ve seen people saying that AI tools don’t handle Perl well. That has not been my experience.

With a properly described issue, repository instructions, and a defined development environment, Copilot works competently with:

• Modern Perl syntax
• CPAN distribution layouts
• Test suites
• Feature::Compat::Class (or whatever OO framework I’m using on a particular project)

The constraint isn’t the language. It’s how clearly you explain the task.

The Real Shift

The most interesting thing here isn’t that Copilot writes Perl. It’s that GitHub allows you to treat AI as a contributor.

• You file an issue.
• You assign it.
• You supervise its reasoning.
• You review its PR.

It’s not autocomplete. It’s not magic. It’s just another developer on the project. One who works quickly, doesn’t argue, and reads your documentation very carefully.

Have you been using AI tools to write or maintain Perl code? What successes (or failures!) have you had? Are there other tools I should be using?

Links

If you want to have a closer look at the issues and PRs I’m talking about, here are some links?

• WebServer::DirIndex repo
• Closed issues
• Closed PRs

The post Treating GitHub Copilot as a Contributor first appeared on Perl Hacks.

Originally published at Perl Weekly 760

Hi there,

Perl's asynchronous ecosystem continues to grow, enabling developers to build non-blocking, responsive applications with ease. Modules like IO::Async, async features in Mojolicious, and helpers for asynchronous database operations (such as DBIx::Class::Async) allow event-driven designs, background tasks, and futures/promises, making high-throughput web services, real time APIs, and streaming pipelines straightforward to implement.

Projects like PAGI and PAGI::Server, now with HTTP/2 support, and Thunderhorse showcase how Perl can handle multiple connections efficiently while keeping code clear and maintainable. Together, these tools make it easier to build responsive, scalable, and maintainable applications, all while retaining the expressive, pragmatic style that continues to define Perl.

With each new module and project, Perl's potential in the modern, concurrent world keeps expanding, the best is yet to come.

A small milestone reached with this issue, my 200th edition. Enjoy rest of the newsletter and stay safe.

--
Your editor: Mohammad Sajid Anwar.

Announcements

Join us for TPRC 2026 in Greenville, SC!

It’s great to see the announcement for The Perl and Raku Conference 2026 (TPRC) taking shape, with registration opening and plans underway for a vibrant community gathering in Greenville, SC this June. The post reinforces the value of bringing Perl and Raku developers together for talks, workshops, and networking. A highlight on the opensource calendar that strengthens the ecosystem and connects contributors across projects.

This week in PSC (215) | 2026-02-11

In This week in PSC 215, the Perl Steering Council covered a deep discussion around legal identifier name restrictions for security without reaching consensus and planning to broaden the conversation beyond p5p, tackled the challenge of an absent maintainer for the dual‑life Encode module, and decided to hold off on merging larger PRs like magic v2 and attributes v2 due to the upcoming freeze in this release cycle. These updates give a clear snapshot of ongoing governance and core maintenance decisions within the Perl project.

Articles

Poplar Decisions

The post reflects on the challenge of rational decision‑making with a quirky, human‑centred anecdote, weaving in the idea that structured data models, like decision trees, can help bring objectivity to complex choices. The post’s blend of storytelling and commentary on data structures adds a thoughtful and entertaining perspective for programmers thinking about reasoning and modeling in code.

Mojo with WebSocket

A practical real‑world example of using Mojolicious’ built‑in WebSocket support to build an interactive online chat app in Perl, complete with multiple server variants and integration options like Redis or PostgreSQL. The repository showcases how easily Mojolicious can handle real‑time bidirectional communication with WebSockets, making it a solid reference for Perl developers exploring event‑driven web apps.

Coding Agents using Anthropic and z.ai - presentation at the German Perl Workshop 2026

The post previews Max's talk at the German Perl Workshop 2026, exploring how modern AI coding agents from Anthropic and z.ai can assist with Perl development, what differences exist between the models, and tips for getting them to write good code. It’s an engaging look at practical uses of agentic AI in real world programming contexts, a timely topic for anyone curious about AI‑assisted development.

Beautiful Perl feature: 'local', for temporary changes to global variables

This article highlights one of Perl’s unique strengths, the local keyword, showing how it enables temporary, dynamic changes to global variables without permanent side effects. With clear examples manipulating %ENV, special Perl variables and even symbol table entries, it makes a compelling case for using local judiciously to solve real world problems that lexical scoping alone can’t.

CPAN

PAGI::Server, now with HTTP/2!

The announcement of PAGI::Server 0.001017 highlights experimental HTTP/2 support built on nghttp2, bringing both cleartext h2c and TLS‑based HTTP/2 to Perl web services with automatic protocol detection and solid h2spec compliance. The write‑up explains why HTTP/2 matters for backend performance and modern use cases like gRPC and multiplexed APIs, and it also outlines other quality‑of‑life improvements and operational fixes in the release.

Black box test generator version 0.28 released

Version 0.28 of App::Test::Generator, the black‑box test case generator, has just been released with improved schema extraction and test generation accuracy, tightening detection of getter/setter methods and better typing in generated tests. These enhancements make it easier to produce honest, robust fuzz and corpus driven test harnesses from your Perl modules.

Run::WeeklyChallenge

Run::WeeklyChallenge is a small but useful CPAN module that helps you automate running solutions to challenges from The Weekly Challenge site by passing one or more sets of JSON‑formatted inputs to your code. It cleanly wraps your solution logic and input schema validation, making it easier to test and reuse challenge solutions programmatically.

DBIx::Class::Async

DBIx::Class::Async is a modern asynchronous wrapper for DBIx::Class that allows non‑blocking database operations in Perl, keeping the familiar DBIC interface while running queries in the background via futures. The latest update brings several improvements: caching is now disabled by default (TTL 0), automatic detection of non-deterministic SQL functions (like NOW() and RAND()) ensures safe bypass of caching, cache invalidation on update/delete operations is more precise using primary keys, and count() queries are no longer cached to guarantee accurate row counts. These enhancements make asynchronous DBIC usage both safer and more reliable.

Syntax::Highlight::Engine::Kate

Syntax::Highlight::Engine::Kate provides Perl programs with robust syntax highlighting using the same engine as the Kate editor. The latest update fixes Issue #23 in Template.pm: the testDetectSpaces() regex was corrected, ensuring only spaces and tabs are matched and improving number highlighting in Perl and other languages. The test suite expected outputs were also updated to reflect the corrected highlighting behavior.

The Weekly Challenge

The Weekly Challenge by Mohammad Sajid Anwar will help you step out of your comfort-zone. You can even win prize money of $50 by participating in the weekly challenge. We pick one champion at the end of the month from among all of the contributors during the month, thanks to the sponsor Lance Wicks.

The Weekly Challenge - 361

Welcome to a new week with a couple of fun tasks "Zeckendorf Representation" and "Find Celebrity". If you are new to the weekly challenge then why not join us and have fun every week. For more information, please read the FAQ.

RECAP - The Weekly Challenge - 360

Enjoy a quick recap of last week's contributions by Team PWC dealing with the "Text Justifier" and "Word Sorter" tasks in Perl and Raku. You will find plenty of solutions to keep you busy.

TWC360

This write-up delivers straightforward, idiomatic Perl solutions for both text justification and word sorting, showing practical use of fc for case-insensitive comparisons and clear subroutine design. The concise code examples make the challenge solutions easy to follow and apply.

Full Circle

In this post, an effective solution to The Weekly Challenge #360 is given, with beautiful examples showing how Raku can be implemented for text justification and sorting as the output. Most of the explanations are fairly short, but they are clearly defined, giving lots of examples; and, they consider the idiomatic usage of Raku's features to make the output readable and helpful.

Pertaining to a subtlety of sorting

This article offers a thoughtful take on the Word Sorter task from PWC 360, with a clear explanation of the case-insensitive sort and an efficient Perl solution using a Schwartzian transform. The benchmarking insight and attention to Unicode case folding nuance show both practical coding skill and depth of understanding.

Perl Weekly Challenge: Week 360

This write-up clearly presents both Text Justifier and Word Sorter tasks with simple, idiomatic Perl and Raku solutions that showcase practical string manipulation and sorting techniques. The inclusion of multiple examples and cross-language snippets makes the challenge approachable and highlights the expressive power of each language.

Perl Weekly Challenge 360

This post showcases clear, idiomatic Perl solutions for both the Text Justifier and Word Sorter tasks, with one‑liner examples and concise logic that demonstrate practical use of integer arithmetic and case‑preserving sorting. The included sample inputs and outputs make the behavior easy to follow and verify.

This is exactly the sort of justification that I was looking for

This post methodically implements both Text Justifier and Word Sorter solutions for PWC 360 in clear Perl code, showing careful step-by-step padding logic and idiomatic sorting. The explanations of how the examples are handled make the approach easy to follow and instructive for readers.

Justifying TIMTOWTDI

The post offers well‑structured Perl solutions that clearly implement both text justification and alphabetical word sorting with idiomatic constructs and practical tests. The use of case‑preserving sorting and centered padding logic demonstrates good command of Perl’s core features and makes the solutions easy to follow and reuse.

Word Crimes are Justified

An excellent and clear walk-through of the Perl Weekly Challenge tasks, with well-structured multi-language solutions and thoughtful explanations that make the text justification and word sorting problems easy to follow. The blend of Perl, Raku, Python, and Elixir examples shows both depth and versatility of approach.

Padding and sorting

The post presents the Text Justifier and Word Sorter tasks clearly with well-explained inputs and desired outputs, giving readers a solid grounding in the problem definitions. The examples are practical and show the expected string centering and alphabetical ordering behavior in a way that supports straightforward implementation.

The Weekly Challenge - 360: Text Justifier

This post demonstrates a practical and idiomatic Perl solution by leveraging String::Pad for Text Justifier, showcasing how using existing modules can simplify challenge tasks. The concise examples with clear input/output make it easy to grasp the task mechanics and verify correctness.

The Weekly Challenge - 360: Word Sorter

This write-up delivers a succinct and idiomatic Perl solution to the Word Sorter task, using a case-insensitive sort and clean split/grep logic that keeps words unchanged while ordering them alphabetically. The included test cases make the behavior clear and easy to verify.

Justify the Words

This post delivers clear and well-commented solutions to both Text Justifier and Word Sorter tasks from The Weekly Challenge 360, using concise Lua, Raku, Perl and other language examples with practical explanations of key steps like centered padding and case-insensitive sorting. The author’s discussion of different implementation strategies highlights thoughtful coding decisions that make the techniques accessible and educational for readers.

Padding and sorting

This write‑up walks through both the Text Justifier and Word Sorter tasks from The Weekly Challenge 360 with clear Python and Perl solutions, showing well‑structured logic for string padding and case‑insensitive sorting. The practical examples and side‑by‑side language implementations make the techniques easy to understand and apply.

Perl Power: Two Tiny Scripts, Big Learning!

This write‑up distills both Text Justifier and Word Sorter solutions into clean, minimal Perl scripts with clear logic for padding and sorting, and emphasizes solid test‑driven development and edge‑case handling. The examples and explanation of core techniques make it both beginner‑friendly and technically sound.

Rakudo

2026.06 CÔD YN GYMRAEG

Weekly collections

NICEPERL's lists

Great CPAN modules released last week.

The corner of Gabor

A couple of entries sneaked in by Gabor.

WhatsApp

Do you use WhatsApp? Join the Perl Maven chat group!

Events

Paris.pm monthly meeting

March 11, 2025

German Perl/Raku Workshop 2026 in Berlin

March 16-18, 2025

The Perl and Raku Conference 2026

June 26-29, 2026, Greenville, SC, USA

You joined the Perl Weekly to get weekly e-mails about the Perl programming language and related topics.

Want to see more? See the archives of all the issues.

Not yet subscribed to the newsletter? Join us free of charge!

(C) Copyright Gabor Szabo
The articles are copyright the respective authors.

Beautiful Perl series

This post is part of the beautiful Perl features series.
See the introduction post for general explanations about the series.

The last post was about BLOCKs and lexical scoping, a feature present in almost all programming languages. By contrast, today's topic is about another feature quite unique to Perl : dynamic scoping, introduced through the 'local' keyword. As we shall see, lexical scoping and dynamic scoping address different needs, and Perl allows us to choose the scoping strategy most appropriate to each situation.

Using local : an appetizer

Let us start with a very simple example:

say "current time here is ", scalar localtime;

foreach my $zone ("Asia/Tokyo", "Africa/Nairobi", "Europe/Athens") {
  local $ENV{TZ} = $zone;
  say "in $zone, time is ", scalar localtime;
}

say "but here current time is still ", scalar localtime;

Perl's localtime builtin function returns the time "in the current timezone". On Unix-like systems, the notion of "current timezone" can be controlled through the TZ environment variable, so here the program temporarily changes that variable to get the local time in various cities around the world. At the end of the program, we get back to the usual local time. Here is the output:

current time here is Sun Feb  8 22:21:41 2026
in Asia/Tokyo, time is Mon Feb  9 06:21:41 2026
in Africa/Nairobi, time is Mon Feb  9 00:21:41 2026
in Europe/Athens, time is Sun Feb  8 23:21:41 2026
but here current time is still Sun Feb  8 22:21:41 2026

The gist of that example is that:

1. we want to call some code not written by us (here: the localtime builtin function);
2. the API of that code does not offer any parameter or option to tune its behaviour according to our needs; instead, it relies on some information in the global state of the running program (here: the local timezone);
3. apart from getting our specific result, we don't want the global state to be durably altered, because this could lead to unwanted side-effects.

Use cases similar to this one are very common, not only in Perl but in every programming language. There is always some kind of implicit global state that controls how the program behaves internally and how it interacts with its operating system: for example environment variables, command-line arguments, open sockets, signal handlers, etc. Each language has its strategies for dealing with the global state, but often the solutions are multi-faceted and domain-specific. Perl shines because its local mechanism covers a very wide range of situations in a consistent way and is extremely simple to activate.

Before going into the details, let us address the bad reputation of dynamic scoping. This mechanism is often described as something that should be absolutely avoided because it implements a kind of action at distance, yielding unpredictable program behaviour. Yes, it is totally true, and therefore languages that only have dynamic scoping are not suited for programming-in-the-large. Yet in specific contexts, dynamic scoping is acceptable or even appropriate. The most notable examples are Unix shells and also Microsoft Powershell for Windows, that still today all rely on dynamic scoping, probably because it's easier to implement.

Perl1 also used dynamic scoping in its initial design, presumably for the same reason of easiness of implementation, and also because it was heavily influenced by shell programming and was addressing the same needs. When later versions of Perl evolved into a general-purpose language, the additional mechanism of lexical scoping was introduced because it was indispensable for larger architectures. Nevertheless, dynamic scoping was not removed, partly for historical reasons, but also because action at distance is precisely what you want in some specific situations. The next chapters will show you why.

The mechanics of local

In the last post we saw that a my declaration declares a new variable, possibly shadowing a previous variable of the same name. By contrast, a local declaration is only possible on a global variable that already exists; the effect of the declaration is to temporarily push aside the current value of that global variable, leaving room for a new value. After that operation, any code anywhere in the program that accesses the global variable will see the new value ... until the effect of local is reverted, namely when exiting the scope in which the local declaration started.

Here is a very simple example, again based on the %ENV global hash. This hash is automatically populated with a copy of the shell environment when perl starts up. We'll suppose that the initial value of $ENV{USERNAME}, as transmitted from the shell, is Alex:

sub greet_user ($salute) {
  say "$salute, $ENV{USERNAME}";
}

greet_user("Hello");                 # Hello, Alex

{ local $ENV{USERNAME} = 'Brigitte';
  greet_user("Hi");                  # Hi, Brigitte

  { local $ENV{USERNAME} = 'Charles';
    greet_user("Good morning");      # Good morning, Charles
  }

  greet_user("Still there");         # Still there, Brigitte
}

greet_user("Good bye");              # Good bye, Alex

The same thing would work with a global package variable:

our $username = 'Alex';             # "our" declares a global package variable

sub greet_user ($salute) {
  say "$salute, $username";
}

greet_user("Hello");
{ local $username = 'Brigitte';
  greet_user("Hi");
  ... etc.

but if the variable is not pre-declared, we get an error:

Global symbol "$username" requires explicit package name (did you forget to declare "my $username"?)

or if the variable is pre-declared as lexical through my $username instead of our $username, we get another error:

Can't localize lexical variable $username

So the local mechanism only applies to global variables. There are three categories of such variables:

1. standard variables of the Perl interpreter;
2. package members (of modules imported from CPAN, or of your own modules). This includes the whole symbol tables of those packages, i.e. not only the global variables, but also the subroutines or methods;
3. what the Perl documentation calls elements of composite types, i.e. individual members of arrays or hashes. Such elements can be localized even if the array or hash is itself a lexical variable, because while the entry point to the array or hash may be on the execution stack, its member elements are always stored in global heap memory. This last category of global variables is perhaps more difficult to understand, but we will give examples later to make it clear.

As we can see, the single and simple mechanism of dynamic scoping covers a vast range of applications! Let us explore the various use cases.

Localizing standard Perl variables

The Perl interpreter has a number of builtin special variables, listed in perlvar. Some of them control the internal behaviour of the interpreter; some other are interfaces to the operating system (environment variables, signal handlers, etc.). These variables have reasonable default values that satisfy most common needs, but they can be changed whenever needed. If the change is for the whole program, a regular assignment instruction is good enough; but if it is for a temporary change in a specific context, localis the perfect tool for the job.

Internal variables of the interpreter

The examples below are typical of idiomatic Perl programming: altering global variables so that builtin functions behave differently from the default.

# input record separator ($/)
my @lines         = <STDIN>;                     # regular mode, separating by newlines
my @paragraphs    = do {local $/ = ""; <STDIN>}; # paragraph mode, separating by 2 or more newlines
my $whole_content = do {local $/; <STDIN>};      # slurp mode, no separation

# output field and output record separators
sub write_csv_file ($rows, $filename) {
  open my $fh, ">:unix", $filename or die "cannot write into $filename: $!";
  local $, = ",";               # output field separator -- inserted between columns
  local $\ = "\r\n";            # output row separator   -- inserted between rows
  print $fh @$_ foreach @$rows; # assuming that each member of @$rows is an arrayref
}

# list separator in interpolated strings
my @perl_files   = <*.pl>; # globbing perl files in the current directory
my @python_files = <*.py>; # idem for python files
{ local $" = ", ";         # lists will be comma-separated when interpolated in a string
  say "I found these perl files: @perl_files and these python files: @python_files";
}

Interface to the operating system

We have already seen two examples involving the %ENV hash of environment variables inherited from the operating system. Likewise, it is possible to tweak the @ARGV array before parsing the command-line arguments. Another interesting variable is the %SIG hash of signal handlers, as documented in perlipc:

{ local $SIG{HUP} = "IGNORE"; # don't want to be disturbed for a while
  do_some_tricky_computation();
}

Predefined handles like STDIN, STDOUT and STDERR can also be localized:

say "printing to regular STDOUT";
{ local *STDOUT;
  open STDOUT, ">", "captured_stdout.txt" or die $!;
  do_some_verbose_computation();
}
say "back to regular STDOUT";

Localizing package members

Package global variables

Global variables are declared with the our keyword. The difference with lexical variables (declared with my) is that such global variables are accessible, not only from within the package, but also from the outside, if prefixed by the package name. So if package Foo::Bar declares our ($x, @a, %h), these variables are accessible from anywhere in the Perl program under $Foo::Bar::x, @Foo::Bar::a or %Foo::Bar::h.

Many CPAN modules use such global variables to expose their public API. For example, the venerable Data::Dumper chooses among various styles for dumping a data structure, depending on the $Data::Dumper::Indent variable. The default (style 2) is optimized for readability, but sometimes the compact style 0 is more appropriate:

print Dumper($data_tree);
print do {local $Data::Dumper::Indent=0; Dumper($other_tree)};

Carp or URI are other examples of well-known modules where global variables are used as a configuration API.

Modules with this kind of architecture are often pretty old; more recent modules tend to prefer an object-oriented style, where the configuration options are given as options to the new() method instead of using global variables. Of course the object-oriented architecture offers better encapsulation, since a large program can work with several instances of the same module, each instance having its own configuration options, without interference between them. This is not to say, however, that object-oriented configuration is always the best solution: when it comes to tracing, debugging or profiling needs, it is often very convenient to be able to tune a global knob and have its effect applied to the whole program: in those situations, what you want is just the opposite of strict encapsulation! Therefore some modules, although written in a modern style, still made the wise choice of leaving some options expressed as global variables; changing these options has a global effect, but thanks to local this effect can be limited to a specific scope. Examples can be found in Type::Tiny or in List::Util.

Subroutines (aka monkey-patching)

Every package has a symbol table that contains not only its global variables, but also the subroutines (or methods) declared in that package. Since the symbol table is writeable, it is possible to overwrite any subroutine, thereby changing the behaviour of the package - an operation called monkey-patching. Of course monkey-patching could easily create chaos, so it should be used with care - but in some circumstances it is extremely powerful and practical. In particular, testing frameworks often use monkey-patching for mocking interactions with the outside world, so that the internal behaviour of a sofware component can be tested in isolation.

The following example is not very realistic, but it's the best I could come up with to convey the idea in just a few lines of code. Consider a big application equipped with a logger object. Here we will use a logger from Log::Dispatch:

use Log::Dispatch;
my $log = Log::Dispatch->new(
  outputs   => [['Screen', min_level => 'info', newline => 1]],
);

The logger has methods debug(), info(), error(), etc. for accepting messages at different levels. Here it is configured to only log messages starting from level info; so when the client code calls info(), the message is printed, while calls to debug() are ignored. As a result, when the following routine is called, we normally only see the messages "start working ..." and "end working ...":

sub work ($phase) {
  $log->info("start working on $phase");
  $log->debug("weird condition while doing $phase"); # normally not seen - level below 'info'
  $log->info("end working on $phase\n");
}

Now suppose that we don't want to change the log level for the whole application, but nevertheless we need to see the debug messages at a given point of execution. One (dirty!) way of achieving this is to temporarily treat calls to debug() as if they were calls to info(). So a scenario like

work("initial setup");
{ local *Log::Dispatch::debug = *Log::Dispatch::info; # temporarily alias the 'debug' method to 'info'
  work("core stuff")}
work("cleanup");

logs the following sequence:

start working on initial setup
end working on initial setup

start working on core stuff
weird condition while doing core stuff
end working on core stuff

start working on cleanup
end working on cleanup

Monkey-patching techniques are not specific to Perl; they are used in all dynamic languages (Python, Javascript, etc.), not for regular programming needs, but rather for testing or profiling tasks. However, since other dynamic languages do not have the local mechanism, temporary changes to the symbol table must be programmed by hand, by storing the initial code reference in a temporary variable, and restoring it when exiting from the monkey-patched scope. This is a bit more work and is more error-prone. Often there are library modules for making the job easier, though: see for example https://docs.pytest.org/en/7.1.x/how-to/monkeypatch.html in Python.

Monkey-patching in a statically-typed language like Java is more acrobatic, as shown in Nicolas Fränkel's blog.

Localizing elements of arrays or hashes

The value of an array at a specific index, or the value of a hash for a specific key, can be localized too. We have already seen some examples with the builtin hashes %ENV or %SIG, but it works as well on user data, even when the data structure is several levels deep. A typical use case for this is when a Web application loads a JSON, YAML or XML config file at startup. The config data becomes a nested tree in memory; if for any reason that config data must be changed at some point, local can override a specific data leaf, or any intermediate subtree, like this:

local $app->config->{logger_file} = '/opt/log/special.log';
local $app->config->{session}     = {storage => '/opt/data/app_session',
                                     expires => 42900,
                                    };

Another example can be seen in my Data::Domain module. The job of that module is to walk through a datatree and check if it meets the conditions expected by a "domain". The inspect() method that does the checking sometimes needs to know at which node it is currently located; so a $context tree is worked upon during the traversal and passed to every method call. With the help of local, temporary changes to the shape of $context are very easy to implement:

  for (my $i = 0; $i < $n_items; $i++) {
    local $context->{path} = [@{$context->{path}}, $i];
    ...

An alternative could have been to just push $i on top of the @{$context->{path}} array, and then pop it back at the end of the block. But since this code may call subclasses written by other people, with little guarantee on how they would behave with respect to $context->{path}, it is safer to localize it and be sure that $context->{path} is in a clean state when starting the next iteration of the loop. Interested readers can skim through the source code to see the full story. A similar technique can also be observed in Catalyst::Dispatcher.

A final example is the well-known DBI module, whose rich API exploits several Perl mechanisms simultaneously. DBI is principally object-oriented, except that the objects are called "handles"; but in addition to methods, handles also have "attributes" accessible as hash members. The DBI documentation explicitly recommends to use local for temporary modifications to the values of attributes, for example for the RaiseError attribute. This is interesting because it shows a dichotomy between API styles: if DBI had a purely object-oriented style, with usual getter and setter methods, it would be impossible to use the benefits of local - temporary changes to an attribute followed by a revert to the previous value would have to be programmed by hand.

How other languages handle temporary changes to global state

As argued earlier, the need for temporary changes to global state occurs in every programming language, in particular for testing, tracing or profiling tasks. When dynamic scoping is not present, the most common solution is to write specific code for storing the old state in a temporary variable, implement the change for the duration of a given computation, and then restore the old state. A common best practice for such situations is to use a try ... finally ... construct, where restoration to the old state is implemented in the finally clause: this guarantees that even if exceptions occur, the code exits with a clean state. Most languages do possess such constructs - this is definitely the case for Java, JavaScript and Python.

Python context managers

Python has a mechanism more specifically targeted at temporary changes of context : this is called context manager, triggered through a with statement. A context manager implements special methods __enter__() and __exit__() that can be programmed to operate changes into the global context. This technique offers more precision than Perl's local construct, since the enter and exit methods are free to implement any kind of computation; however it is less general, because each context manager is specialized for a specific task. Python's contextlib library provides a collection of context managers for common needs.

Wrapping up

Perl's local mechanism is often misunderstood. It is frowned upon because it breaks encapsulation - and this criticism is perfectly legitimate as far as regular programming tasks are concerned; but on the other hand, it is a powerful and clean mechanism for temporary changes to the global execution state. It solves real problems with surprising grace, and it’s one of the features that makes Perl uniquely expressive among modern languages. So do not follow the common advice to avoid local at all costs, but learn to identify the situations where local will be a helpful tool to you!

Beyond the mere mechanism, the question is more at the level of philosophy of programming: to which extent should we enforce strict encapsulation of components? In an ideal world, each component has a well-defined interface, and interactions are only allowed to go through the official interfaces. But in a big assembly of components, we may encounter situations that were not foreseen by the designers of the individual components, and require inserting some additional screws, or drilling some additional holes, so that the global assembly works satisfactorily. This is where Perl's local is a beautiful device.

About the cover picture

The cover picture¹ represents a violin with a modified global state: the two intermediate strings are crossed! This is the most spectacular example of scordatura in Heirich Biber's Rosary sonatas (sometimes also called "Mystery sonatas"). Each sonata in the collection requires to tune the violin in a specific way, different from the standard tuning in fifths, resulting in very different atmospheres. It requires some intellectual gymnastics from the player, because the notes written in the score no longer represent the actual sounds heard, but merely refer to the locations of fingers on a normal violin; in other words, this operation is like monkey-patching a violin!

1. CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=110521795 ↩