Don't add prototypes to your subroutine declaration. Adding the empty round brackets after the subroutine name, means that this subroutine will not take any parameters! Obviously this is incorrect. Just drop the round brackets and forget you ever heard anything about Perl subroutine prototypes.

Don't call your subroutines with a prepended "&". It is "old style" dating back to Perl 4! The effect of it now is that any prototypes are ignored. In the few cases they are actually usefully used, you surely do not want to do that and in all other cases it saves you one character less to type.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Actually in this case the "&" is meaningful. There is a Perl built-in called read, so the "&" serves as disambiguation, proving that you want to call the sub, and not the built-in.

Of course, the wisdom of defining a function with the same name as a Perl built-in is debatable. Sometimes it makes sense (e.g. each in Set::Scalar is designed to be used as a method, so never looks ambiguous in code. Naming it same as the built-in serves as a hint as to its purpose.) but I'm not sure this is one of those times.

In this case it is not meaningful to recycle a built-in keyword and even far less meaningful to add a totally wrong prototype (and then call the sub without regard to prototypes).

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Don't call your subroutines with a prepended "&". It is "old style" dating back to Perl 4! The effect of it now is that any prototypes are ignored. In the few cases they are actually usefully used, you surely do not want to do that and in all other cases it saves you one character less to type.

Yeah, except in this case, things will break.

Please, think before giving Pavlov reactions. Don't trigger a standard response to seeing a &sub. The use of &read is completely justified in this case, and your suggestion will break the construct. And not because of the prototype.

Besides, there's no need to look down on constructs that predate Perl5. Regular expressions are "perl4" (actually, older than that). Many keywords are from the pre-perl5 era. And it's kind of silly to first say "don't use prototypes - in fact, try to forget they exist" and then "don't use &sub, because that bypasses prototypes".

I totally agree that when following my advice the script will break. And for good reasons, since there is no good reason why you want to "re-cycle" a built-in keyword and then you can only make your bad choice of a sub-routine name work by using a construct that has an unwanted (and I am quite sure, unknown to the OP) side-effect.

I think my "standard response" to using prototypes and the calling of subs with "&" is correct. Someone adds a wrong prototype to the sub-definition (I repeat, probably blissfully unaware of what he did) and then you need to set aside the prototype to make it work. Please, explain to me the merit of this kind of programming.

In Perl 4 you had to prepend "&" to the sub-name to call it. In Perl 5 the meaning of "&" has totally changed.

And I challenge you to proof that adding "&" to all your sub-calls is not silly. Some subs that work like built-ins need the prototyping to work.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James