Does this help you?

s[ 
    (         ## Capture
        \(      ## from an open paren
        [^)]+   ## all non-close paren chars
        \)      ## upto the close paren
    ) 
][ 
    ## assign the captured text 
    ## to a local variable so that it can be edited
    ## and then replace all ,s with ;s
    ( my $x = $1 ) =~ tr[,][;];
    ## and return the modified text to replace that captured.
    $x 
]
g  ## globally
e  ## execute the replace as code 
x; ## extended notation to allow whitespace and comments
[download]

Bravo.   Code written in this way would be instantly apparent to anyone who encountered it, and of course it would make no difference to the Perl compiler.

I am a very big believer in writing code in this way, and also in keeping a daily “running log,” or diary, in which I talk to myself about what I am doing and why.   Every developer on my teams is asked to keep an ongoing project diary within the repository and to review one another’s entries from time to time.   You don’t remember nearly as much detail as you suppose, not even about things that you did and even that you did recently.

Fav’d.

Code written in this way would be instantly apparent to anyone who encountered it,

Aside from the fact that [^)]+   ## all non-close paren chars would mean nothing to anyone who doesn't have at least a passing familiarity with regex notation, writing every regex out this way in production code would be bordering upon the criminal.

I can't think of a single other occupation where apparently sober, experienced exponents suggest that they should do their work such that a beginner can immediately understand everythng they did without expending a little effort.

Take music. When starting to learn to play an instrument, you are likely to be given a score that looks something like this.

But no musician would advocate giving that to professional musicians instead of this.

Do you expect employers to pay for you to spend 10s of minutes of their time formatting and annotating a regex over 20+ lines of their source code, when it took no more than a few seconds to type it -- including the time it took to work out what to type -- on one short line?

When someone is learning and asks for help, I have no problems at all in expending time and effort annotating that line of code -- for them.

But wasting time and effort writing every line of production code as if it might one day need to be understood and modified by my 8 y/o niece, or the guy that came to fill the water cooler -- just in case. I've more respect for the use of my time and my employer's money.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Familiarity with the resources found in docs on the internet (and, in many cases, on your own machine) can help you achieve your stated goal, "...not have to resort to Perl Monks (too often)....".

So, right at your desk, perldoc -f function_name and perldoc modulename are invaluable. But, first, it'll also be worth your time to explore perldoc perldoc, (for help on how to use perldoc) and perldoc perltoc second... for the kinds of documentation available.