Perl iterate over a list sub process

A Perl script can look deceptively simple when all it needs to do is walk through a list and perform an operation. The interesting part begins when that operation is moved into a separate subroutine, because then questions about arguments, scope, references, return values, and list handling start to matter. This is where understanding how Perl iterate over a list sub process works becomes useful rather than simply memorizing a foreach loop.

Perl gives you several ways to iterate over list data, but the basic pattern remains readable: obtain an item, pass it to a subroutine, process it, and then continue with the next item. The choice between foreach, for, map, references, and other techniques depends on what the program actually needs to accomplish. A small script may need only a few lines, while production code may need careful handling of empty lists, large datasets, side effects, and errors.

Background and context

When Perl works with a list, the program normally needs a way to visit each element individually. A foreach loop is one of the clearest ways to do this — especially when the processing logic belongs in a separate subroutine (which keeps the loop easier to read).

Consider a list of names:

my @names = ("Amit", "Priya", "Rahul", "Neha");

The variable @names contains four scalar values. A loop can assign each value to a temporary scalar:

foreach my $name (@names) {
    print "$name\n";
}

Here, $name represents one element at a time. Perl processes the first name, then the second, then the third, and so on.

The foreach keyword and for keyword are interchangeable in Perl for this purpose. These two examples behave the same:

foreach my $name (@names) {
    print "$name\n";
}

for my $name (@names) {
    print "$name\n";
}

The important distinction comes when the operation becomes larger. Instead of putting every statement inside the loop, you can place the work inside a subroutine:

sub process_name {
    my ($name) = @_;
    print "Processing: $name\n";
}

for my $name (@names) {
    process_name($name);
}

The special array @_ contains the arguments passed to the subroutine. my ($name) = @_; extracts the first argument into the lexical variable $name.

And that simple separation creates a useful boundary: the loop controls iteration, while the subroutine controls processing.

The main substance

The most common pattern for Perl iterate over a list sub process is to define a subroutine that accepts one list element and call it from a foreach loop.

my @numbers = (10, 20, 30, 40, 50);

sub process_number {
    my ($number) = @_;
    my $result = $number * 2;

    print "$number -> $result\n";
}

for my $number (@numbers) {
    process_number($number);
}

The execution flow is straightforward. Perl assigns 10 to $number, calls process_number(10), completes the subroutine, and then moves to 20. The same process continues until every element has been visited.

A useful detail is that the loop variable can be declared with my:

for my $item (@items) {
    process_item($item);
}

This gives the variable lexical scope and avoids unnecessary interaction with variables elsewhere in the program.

Subroutines can also accept several values. Suppose every list item contains a product name and price:

my @products = (
    ["Laptop", 50000],
    ["Phone", 25000],
    ["Tablet", 18000]
);

sub process_product {
    my ($name, $price) = @_;

    print "$name costs $price\n";
}

for my $product (@products) {
    process_product($product->[0], $product->[1]);
}

Here, each element of @products is an array reference. The arrow operator accesses values inside that referenced array.

A cleaner version can pass the entire reference:

sub process_product {
    my ($product) = @_;

    my ($name, $price) = @$product;
    print "$name costs $price\n";
}

for my $product (@products) {
    process_product($product);
}

This approach becomes especially useful when the data structure grows.

Another important Perl feature is that a subroutine can receive the entire list rather than one element at a time:

sub process_all {
    my @items = @_;

    for my $item (@items) {
        print "Processing $item\n";
    }
}

process_all(@names);

There is a subtle difference here. Passing @names to process_all passes its values as arguments. Inside the subroutine, @_ receives those values.

If you want the subroutine to work with the original array without copying its values into a new argument list, an array reference is often better:

sub process_all {
    my ($items) = @_;

    for my $item (@$items) {
        print "Processing $item\n";
    }
}

process_all(\@names);

This is particularly useful for large lists or when the subroutine needs to modify the original array.

The distinction matters because Perl passes arguments to subroutines through @_, while references allow a subroutine to access the original data structure — rather than simply receiving separate scalar values.

map is another possibility:

my @results = map { process_item($_) } @items;

But map is designed around producing a transformed list. If the purpose is simply to perform an action for every item, a normal for or foreach loop is usually easier for another developer to understand.

Practical angle

In real Perl programs, the choice of iteration pattern usually depends on what the subroutine is doing. For a small list, this is perfectly reasonable:

for my $file (@files) {
    process_file($file);
}

The subroutine might open a file, validate its contents, calculate a value, or send information to another part of the application. Keeping that logic outside the loop prevents the iteration code from becoming a large block of unrelated operations.

For example:

my @numbers = (2, 4, 6, 8);

sub square {
    my ($number) = @_;
    return $number * $number;
}

for my $number (@numbers) {
    my $result = square($number);
    print "$result\n";
}

The return value is captured normally with $result.

But there is another practical issue: error handling. If process_file() fails for one file, should the whole loop stop? Or should the program report the error and continue? That decision belongs to the application’s requirements, not to Perl itself.

You may also encounter code where the subroutine modifies a value:

sub add_tax {
    my ($price_ref) = @_;

    $$price_ref *= 1.18;
}

for my $price (@prices) {
    add_tax(\$price);
}

Here, a scalar reference is passed so the subroutine can modify the original variable. This is powerful, but it should be used deliberately.

The truth is, simple loops are often preferable to clever Perl expressions. A compact map statement can save lines, but if the operation has side effects or several conditions, a foreach loop usually communicates the programmer’s intention more clearly.

And when the list is very large, memory becomes a separate concern. A normal array already stores its elements in memory, so iterating over it does not magically make the dataset memory-efficient. For very large input, reading records incrementally from a file or using an iterator-style approach may be more appropriate.

What to know going forward

The central idea is easy to carry into more advanced Perl code: let the loop decide which item is being processed, and let the subroutine decide what happens to that item.

A basic pattern looks like this:

for my $item (@list) {
    process_item($item);
}

If the subroutine needs several pieces of information, pass them explicitly:

process_item($name, $price, $quantity);

If it needs to work with the original array itself, pass a reference:

process_items(\@list);

And if the goal is to create a new list from an existing list, consider map instead of using a loop only for transformation.

One caveat deserves attention: Perl’s flexible argument system does not automatically enforce the number or type of arguments a subroutine expects. If correctness matters, validate inputs inside the subroutine or use a suitable validation strategy.

So the best approach is not simply the shortest syntax. It is the pattern that makes the data flow obvious to the next person reading the code.

Closing

A Perl list-processing routine becomes much easier to maintain when iteration and processing have clear responsibilities. Start with for or foreach, pass each element to a focused subroutine, and introduce references when the subroutine needs access to the original data structure.

A useful next step is to take a small loop from your own Perl code and move its processing statements into a subroutine. Then check what the subroutine receives through @_, what it returns, and whether it actually needs a reference. That exercise makes the underlying Perl model much easier to understand.