In short, yes, you do. Here's why:

Loading files into individual arrays such as "@array1", "@array2" ... "@arrayn" logically leads you to the situation where you are hard-coding the array names into your script. Iterating over them means something like this:

foreach my $aref ( \@array1, \@array2, ... \@arrayn ) {...
[download]

So what if "n" changes from three to four? You're stuck; you have to go back into your source code and add a new variable for that new file. It's unmaintainable, and someone using your script would suffer the impatience of knowing that the computer could be doing more for them, if only the programmer had been more lazy (in the positive sort of way).

You might then start to wonder, is it possible to automatically iterate over arrays named @array1, @array2, and so on? ...and if they are set up as package global variables, in fact, it is. But doing so crosses that barrier that "strict 'vars'" explicitly prohibits, because it's generally unsafe, or as some people put it "it's stupid to use a variable as a variable name"... and most of all, because there's usually a better solution; years of CS have moved us mostly away from symbolic style references.

So the solution is to store your files all in an array, or possibly an array of arrays. Let's say you have your list of filenames in an array named "@filenames"; one filename per array element. In that case, you could:

use File::Slurp 'read_file';
my @raw_files;
foreach my $filename ( @filenames ) {
  push @raw_files, scalar read_file( $filename, chomp => 1 );
}
[download]

...and then you should have a data structure that is already appropriate to feed to my script.

Later on, if you're interested in making the code more elegant, you would probably refactor such that as you are reading the file into memory you are handling all the other processing on it such as splitting on whitespace, and even setting it up the elements thereof in hash keys. But that's not strictly necessary in this step, and doing so would require refactoring the rest of my solution as well.