I will be considering a subroutine to bypass the repetitive writing of similar code and provide a centralized chunk of code that can be invoked from anywhere within your program, this carries the advantage of making it easier to debug and trace errors, modify & enhance code later and facilitate adding more capabilities centrally that are going to be dynamically extended to the areas in the program invoking the subroutine without having to write too much code or deal with nasty inadvertent typos for instance.

You can have many subroutines organized by the theme of the activities they will be performing and if necessary they can communicate among themselves, consider this pseudocode:

#define functions in themes
sub dependency_checks{
#receive arguments and perform the checks
#common to the so many if statements
}
#write your program with the rest of the unique section.

Secondly, how do you intend to use @matches, does ordering matter to you in this case or could you avail of the flexibility that a hash based structure has where you can directly retrieve and have access to values without so much hassle, the link you provided implied that hash-based structures are more flexible.

Wow, thanks for all the tips! I was going to make a subroutine, just wasn't sure if I should put everything in it, or only the parts that were **exactly** the same, and then keep the if-elsif structure in the main script. I think I'll stay away from the advanced stuff for now, I think I should learn OO first.

Regarding @matches, I need all the elements pushed to that array to stick together. They will be outputted together. There will be some duplicate values, but after looking at the code, I think it will still be okay to use a hash...

My diagnosis: since @matches will be over-written, duplicate key-value pairs in the matches will still be kept in @all_matches. (ie. different sentences mathed have 3 of the exact same elements in @matches, but it shouldn't matter). I will have to try and see

I need to then sort all the @matches by different criteria ( frequency of matches with the same grammar relation, arg1 and arg2 (which are 3 elements of the 6 in @matches)). Which is why I used @all_matches. So I thought ordering was important. But after reading the Uniqueness of hashes, I may be able to utilize some of those counting duplicate methods. Thanks a lot!

"Can I reward good answers on this site?" Yes, once you've accrued a (very little) bit of experience, the Vote Fairy will bring you one or more votes each day. Cast them wisely. See the Voting/Experience System superdoc, a kind of FAQ.

"Just writing this reply sorted some things out in my head..." You have just (re-)discovered the "Teddy Bear technique." Talk your problems out with a silent but sympathetic listener and the answers will often spring full blown (or nearly so) as if from (someone's) forehead.

"I think I'll stay away from the advanced stuff for now, I think I should learn OO first." That's probably a matter*1 of taste and learning style...

...such as the fact that hashes canNOT contain duplicate keys. This, re your observation "There will be some duplicate values, but after looking at the code, I think it will still be okay to use a hash... "

And, not just by-the-way, welcome to the Monastery!

*1 It is also a topic likely to inspire disagreements as vehement as those surrounding such questions as "how many Angels can dance on the head of a pin?" and "Which is the best editor for programming?"

I was going to make a subroutine, just wasn't sure if I should put everything in it, or only the parts that were **exactly** the same...

Subroutines are useful for avoiding repetition, but the best thing about subroutines is that they let you extract and name a little bit of behavior. Most of my small, single-file programs start out with me declaring main() and then calling a bunch of smaller subroutines from there. I fill them in as I go, and I use their names to describe what they do.