From: HerbF on
Uri Guttman wrote:

>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes:
>
> >> sub calls should be made with parens is the common style rule and not
> >> with &.
>
> H> Thanks. Do I understand you to say that &abc; is "wrong" and that I
> H> should be using abc(); instead?
>
>yes. i just said that. so do the docs. please read them as that is the
>best way to learn perl. there is a whole doc just for perl subs.
>
> H> As I'm calling one routine as &abc(A,B,C); what is the correct syntax?
>
>no, drop the & as it is NOT NEEDED nor desirable. it marks your coding
>style as ancient perl4ish. it can cause issues you don't know about.
>parens are all you need and are correct.
>
Thank you.

HF
From: HerbF on
Tad McClellan wrote:

>HerbF(a)earthlink.net <HerbF(a)earthlink.net> wrote:
>> Uri Guttman wrote:
>>
>>>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes:
>>>
>>> H> I typically call subroutines without using parenthesis, e.g., &abc;. I
>>> H> have one routine where I pass variables and I call it as:
>>>
>>>that is poor perl code and perl4 style. don't use & for sub calls as it
>>>has side effects you may not know about. read perldoc perlsub for more.
>>>
>>> H> Should I be using parenthesis at the subroutine, i.e.,
>>>
>>> H> sub abc (A,B,C) {...}
>>>
>>>that has nothing to do with parens at the sub call itself. perl doesn't
>>>support named arguments like you have there so it won't do any good to
>>>try it.
>
>
>What you have there is called a "prototype", they are often a Bad Idea,
>so you shouldn't be using them at all.
>
>If what you want is named arguments, then you typically do that by
>copying the args in the first statement in the subroutine body:
>
> sub abc {
> my($A, $B, $C) = @_;
> ...
>
>But don't choose one-letter variable names!

Of course. :-)
>
>
>>>sub calls should be made with parens is the common style rule and not
>>>with &.
>>>
>> Thanks. Do I understand you to say that &abc; is "wrong" and that I should
>> be using abc(); instead?
>
>
>Yes.
>
>
>> As I'm calling one routine as &abc(A,B,C); what is the correct syntax?
>
>
>abc(A,B,C);
>
>
> perldoc -q difference
>
> What's the difference between calling a function as &foo and foo()?

Thanks very much.

Herb
From: Peter J. Holzer on
On 2010-08-06 21:28, Tad McClellan <tadmc(a)seesig.invalid> wrote:
> HerbF(a)earthlink.net <HerbF(a)earthlink.net> wrote:
>> Uri Guttman wrote:
>>>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes:
>>> H> Should I be using parenthesis at the subroutine, i.e.,
>>>
>>> H> sub abc (A,B,C) {...}

[...]

> What you have there is called a "prototype",

It isn't even a correct prototype. Perl complains with

Illegal character in prototype for main::abc : A,B,C at foo line 3.

if you use warnings at the definition

and with

Malformed prototype for main::abc: A,B,C at foo line 5.

even without warnings and strict when you try to call that sub.

So the OP could have gotten the answer "No" to his question simply by
trying it.

(I really don't understand people who post some code which doesn't work
and ask "Should I do this?" Well, it doesn't work, so obviously you
shouldn't.)

hp

From: Keith Thompson on
"Uri Guttman" <uri(a)StemSystems.com> writes:
>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes:
> H> I typically call subroutines without using parenthesis, e.g., &abc;. I
> H> have one routine where I pass variables and I call it as:
>
> that is poor perl code and perl4 style. don't use & for sub calls as it
> has side effects you may not know about. read perldoc perlsub for more.
>
> H> Should I be using parenthesis at the subroutine, i.e.,
>
> H> sub abc (A,B,C) {...}
>
> that has nothing to do with parens at the sub call itself. perl doesn't
> support named arguments like you have there so it won't do any good to
> try it.
>
> sub calls should be made with parens is the common style rule and not
> with &.

I tend to omit parentheses in many cases where they're not necessary.
For example, I might write:

sub Foo;
...
my $x = Foo 42; # rather than Foo(42)
...
sub Foo {
my($arg) = @_;
return $arg + 1;
}

Would you consider this to be a bad habit? (I don't use "&" on
calls, and I've broken my previous habit of using prototypes.)

I know that parentheses are necessary for something like:

print "Foo 42 = ", Foo(42), "\n";

because without them the "\n" is passed to Foo, not to print.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Uri Guttman on
>>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes:

KT> I tend to omit parentheses in many cases where they're not necessary.
KT> For example, I might write:

KT> sub Foo;
KT> ...
KT> my $x = Foo 42; # rather than Foo(42)
KT> ...
KT> sub Foo {
KT> my($arg) = @_;
KT> return $arg + 1;
KT> }

that only works if you declare Foo before you call it. perl can't tell
if a bareword is a sub if it hasn't seen it before unless you use parens.

look at these examples which show why always using parens is a good thing:

perl -we 'sub foo {print "hello\n" } ; foo'
hello

perl -we 'foo; sub foo {print "hello\n" }'
Unquoted string "foo" may clash with future reserved word at -e line 1.
Useless use of a constant in void context at -e line 1.

perl -we 'foo(); sub foo {print "hello\n" }'
hello

KT> Would you consider this to be a bad habit? (I don't use "&" on
KT> calls, and I've broken my previous habit of using prototypes.)

yes, as i show above. btw, predeclaring also works for exported subs
from a module. still i use parens. only with protoyped subs that need to
look like builtins might i skip the parens.

KT> I know that parentheses are necessary for something like:

KT> print "Foo 42 = ", Foo(42), "\n";

KT> because without them the "\n" is passed to Foo, not to print.

that is a precedence issue, not a predeclared one. if Foo were
predeclared with a prototype of a single arg, the parens wouldn't be
needed and it would work.

uri

--
Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------