printing the result of a procedure call

H

Helmut Richter

What is the difference of

- calling a procedure to get a result, and *then* printing the result

and

- calling a procedure as a parameter of print?

Example:

----> cat ./tt
#! /usr/bin/perl

print "\nfirst try:\n";
$z = proc (1);
print $z;

print "\nsecond try:\n";
print (proc (1));

sub proc {
return "result\n";
};

----> ./tt

first try:
result

second try:

---->

I expected twice the same result.
 
J

Jürgen Exner

Helmut Richter said:
What is the difference of
- calling a procedure to get a result, and *then* printing the result
and
- calling a procedure as a parameter of print?
None.

Example:

----> cat ./tt
#! /usr/bin/perl

print "\nfirst try:\n";
$z = proc (1);
print $z;

print "\nsecond try:\n";
print (proc (1));

sub proc {
return "result\n";
};

----> ./tt

first try:
result

second try:

---->

I expected twice the same result.

But in the second case you didn't call proc().

Why aren't you using strict and warnings? If you had used strict and
warnings then perl would have told you what's wrong.

Solutions:
a: predeclare sub proc;
b: use
print (proc(1));
instead of
print (proc (1));

jue
 
H

Helmut Richter

But in the second case you didn't call proc().

Why aren't you using strict and warnings? If you had used strict and
warnings then perl would have told you what's wrong.

That's correct -- I should have done that.
Solutions:
a: predeclare sub proc;
b: use
print (proc(1));
instead of
print (proc (1));

c: use &proc. This is how I did it for more than a decade, and it works
with a blank after the procedure name as well as without. Now, for
whatever reason, I find it nicer without the &, and I simply did not
expect that it would have so much of an effect in the tiny fraction of
cases where it matters -- probably *only* with print and similar commands.

(In the meantime, it has become fashionable not to write parentheses at
all, but it might take me another decade to get used to it enough to be
able to see where the parameter list ends.)

Thanks to all who responded!
 
W

Wolf Behrenhoff

c: use &proc. This is how I did it for more than a decade, and it works
with a blank after the procedure name as well as without. Now, for
whatever reason, I find it nicer without the &, and I simply did not
expect that it would have so much of an effect in the tiny fraction of
cases where it matters -- probably *only* with print and similar commands.

(In the meantime, it has become fashionable not to write parentheses at
all, but it might take me another decade to get used to it enough to be
able to see where the parameter list ends.)

It is very bad style to use &proc - unless you know what you're doing.
For one thing, the & overrides prototypes. As a second thing, as you
mention leaving out parentheses: note that proc(); and &proc; do
different things. The first form passes an empty argument list, the
second form passes @_! (or maybe better: the first form clears @_ for
the sub proc while &proc does not change @_).

Don't use &proc if you can use proc() instead.

Wolf
 
J

Jürgen Exner

Helmut Richter said:
That's correct -- I should have done that.


c: use &proc.

Hmmmm, no. That would have a quite different semantic.
And if you don't know what that different semantic is then you don't
want to use &proc.
It is a very rare case that &proc is actually useful.

jue
 
H

Helmut Richter

It is very bad style to use &proc - unless you know what you're doing.
For one thing, the & overrides prototypes. As a second thing, as you
mention leaving out parentheses: note that proc(); and &proc; do
different things. The first form passes an empty argument list, the
second form passes @_! (or maybe better: the first form clears @_ for
the sub proc while &proc does not change @_).

Don't use &proc if you can use proc() instead.

I will in the future. But when I learnt perl, &proc was the standard way
of writing procedure calls -- see the camel book, edition March 1992.
Well, the oldest of my scripts I still use on a regular basis is from 2001
-- I have no idea what was then the preferred way of writing procedure
calls. (That's how you discover you're getting real old.) By and large,
language changes have been upward compatible over time, though.

My problem was not language change but ambiguity: what I had written
allowed two different ways of syntactic decomposition, of which I only saw
one. Even if I had seen both, I would not have been able to tell which of
them the compiler/interpreter would assume to be the correct one, and I
see no way to determine that from any language description I have. So "use
warnings" is indeed the right (the only?) way to resolve the ambiguity.
 
U

Uri Guttman

HR> I will in the future. But when I learnt perl, &proc was the
HR> standard way of writing procedure calls -- see the camel book,
HR> edition March 1992. Well, the oldest of my scripts I still use on
HR> a regular basis is from 2001

and perl5 has been out since 1993 with 5.004 (first decent version) out
in 1997. perl4 required the &foo call style and perl5 didn't. so you
have been way out of touch thinking & was needed or normal.

HR> -- I have no idea what was then the preferred way of writing
HR> procedure calls. (That's how you discover you're getting real
HR> old.) By and large, language changes have been upward compatible
HR> over time, though.

perl4 was very compatible with perl5 but that doesn't mean newer ways
didn't obsolete older one. real references made using typeglobs and/or
symbolic references obsolete. calling subs with foo() made &foo
obsolete.

HR> My problem was not language change but ambiguity: what I had
HR> written allowed two different ways of syntactic decomposition, of
HR> which I only saw one. Even if I had seen both, I would not have
HR> been able to tell which of them the compiler/interpreter would
HR> assume to be the correct one, and I see no way to determine that
HR> from any language description I have. So "use warnings" is indeed
HR> the right (the only?) way to resolve the ambiguity.

where have you been for 13 years? you never saw foo() in any perl code
since then? on cpan? cow-orkers? web scripts? it make little sense to
keep programming in a language for 15+ years and not knowing about any
changes in it.

uri
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top