[beginner is learning] How comes before I ask a question here, it is answered

[aquaplanet]

Hey!

I was just about to the second time try to write a question here:

"Why do I get mask ealier declaration when I don't really do a declaration."

Then it suddenly struck me that in the utterly whiny error message that the line numbers was not in order so I fixed the small stuff in line number ordering. Suddenly my error disappeared and all was well.

I "ask this question" mostly because I am a beginner and I bet this will be a problem for other beginners (so reading this for them might help). The fix was btw that I didn't use parentatheses in the function call:

validate_dir $conf{'base'};

was corrected to

validate_dir($conf{'base'});

Ofcourse, as a beginner, I don't understand why I have to use them here when I usually don't but perl is complaining (atleast today, on my computer; it probably haven't sleept too well; because it can't be me who are in error, can it :-) so adding them helps.

Regards

Aquaplanet

[moritz]

I don't know what exactly went wrong in your case, I just want to point out two things:

1. Leaving out the parens for the arguments of a subroutine call is fine if and only if that subroutine is declared previously. If not, it is parsed as indirect method call syntax, which is not what you want
2. Sometimes syntax errors confuse the parser, and you'll first get some errors about undeclared or redefined variables, and then get the message about the real syntax error. In such a case ignore everything except the first syntax error, fix that syntax error, and try again.

[aquaplanet]

1. You are right! I looked at my declarations again and saw that the subroutine was not declared. I have declared stubs of each subroutine in the top to be able to use the subroutines in any order and their implementations in the bottom of the file. However this was not the case...error corrected. Thanks!
2. I guess it is hard in such a big (and expressive) language, experienced similar things in other languages such as C

[Corion]

I would guess that you're witnessing the Teddy Bear Effect, which is the phenomenon of finding a solution by verbally stating your problem.

[aquaplanet]

Probably, goes faster that way! Thanks by the way for a good site you linked me. I found a little bit of interesting parts all over it.

[GrandFather]

There are a number of things it is worth getting into the habit of doing when using Perl to make your life easier but the first and most important is always use strictures (use strict; use warnings; - see The strictures, according to Seuss).

In the context of your specific problem part of the fix is to always use parenthesis in your subroutine calls. To my eye at least that makes it easier to see the calls. Note however that frequently the built in Perl functions are called without using parenthesis which works because all the built in functions are 'predeclared'. Personally I structure my programs with the main code first followed by the subs which is rather the opposite of the way a typical C program is structured, but Perl lets me do it that way if I want whereas C really doesn't want me to if it can help it.

Try not to carry too much C baggage over to Perl. In particular you almost never need to use the C style for loop.

[eyepopslikeamosquito]

This is discussed in Chapter 9, "Subroutines" of Perl Best Practices in the first item "Call subroutines with parentheses but without a leading &". Luckily, Chapter 9 happens to be the free sample chapter from this book. Conway argues that leaving off the parens from user-defined subroutines makes them harder to distinguish from built-ins. See also rule 113 in Vromans PBP reference card.

[BrowserUk]

Conway argues that leaving off the parens from user-defined subroutines makes them harder to distinguish from built-ins.

That might, just, possibly be the case for those very few heroic martyrs who insist on doing everything in green&white and eschewing the benefits of syntax highlighting.

But they are a rare breed indeed. For the rest of us, depending upon our needs and taste, built-ins can be made to stand out--or not--as we so chose.

Were this a truly important distinction for me (or anyone using my editor) to make, then I could have built-ins appear double-bold fluorescent pink letters on a day-glo yellow background. I might even be able to make them flash, though I'm not sure because I've never thought to try.

But I don't, and I doubt you'll find many who would. My argument with this particular piece of "best practice" is not that the argument is wrong, but that it is the wrong argument. Why is it important to make that distinction?

User functions are just as important as built-ins; but no more so. Besides which, most built-ins can be overridden by loaded modules, and many are to good effect. What benefit this distinction then?

Given the effects that book has had, I'm kinda surprised that anyone is still promoting it.

[shmem]

Conway argues that leaving off the parens from user-defined subroutines makes them harder to distinguish from built-ins

and that way trades decoration for understanding. Looks silly to me, to say the least. The language doesn't distinguish builtins from overriden builtin functions via parens, so the riddle remains for the beholder.

Besides, at the place where I work, they cruft perl in a C fashion, and the coding guidelines require parens even for builtins, so "people with less expertise in perl feel familiar and know what's happening" - which statement makes me cringe. A two hour talk would give them FMTTEWTK about parens, functions and context to get perl basics right and feel at ease with parens just as needed.

Oh, and parens around arguments for builtins even don't work always. Take print. Much has been argued against the current implementation of print. I am glad that it is as it is. At least it gives me an argument against folly.

[eyepopslikeamosquito]

Curiously, I also work with "people with less expertise in Perl" and our coding standards similarly mandate always using parens (and no leading &) when calling non built-in subroutines. We had this standard in place long before PBP in response to a specific incident here when an inexperienced Perl programmer simply changed "use" to "require" so as to load his (procedural) module at runtime rather than compile time. Unfortunately, this broke his code that was calling the module's functions without parens, and, due to his inexperience with Perl, he struggled for hours to figure out what was going wrong. If I understand correctly, the OP in this node had a similar problem and similarly spent quite a bit of time figuring it out, time that might have been saved by following this coding standard.

[Anonymous Monk]

What?