Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > printing the result of a procedure call

Reply
Thread Tools

printing the result of a procedure call

 
 
Helmut Richter
Guest
Posts: n/a
 
      09-26-2010
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.

--
Helmut Richter
 
Reply With Quote
 
 
 
 
Jürgen Exner
Guest
Posts: n/a
 
      09-26-2010
Helmut Richter <(E-Mail Removed)> wrote:
>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
 
Reply With Quote
 
 
 
 
Helmut Richter
Guest
Posts: n/a
 
      09-27-2010
On Sun, 26 Sep 2010, wrote:

> 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!

--
Helmut Richter
 
Reply With Quote
 
Wolf Behrenhoff
Guest
Posts: n/a
 
      09-27-2010
On 27.09.2010 09:30, Helmut Richter wrote:
> 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
 
Reply With Quote
 
Jürgen Exner
Guest
Posts: n/a
 
      09-27-2010
Helmut Richter <(E-Mail Removed)> wrote:
>On Sun, 26 Sep 2010, wrote:
>
>> 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.


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
 
Reply With Quote
 
Helmut Richter
Guest
Posts: n/a
 
      09-27-2010
On Mon, 27 Sep 2010, Wolf Behrenhoff wrote:

> On 27.09.2010 09:30, Helmut Richter wrote:
> > 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.


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.

--
Helmut Richter
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      09-27-2010
>>>>> "HR" == Helmut Richter <(E-Mail Removed)> writes:

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


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

--
Uri Guttman ------ http://www.velocityreviews.com/forums/(E-Mail Removed) -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
procedure as argument in procedure AlexWare VHDL 2 10-23-2009 09:14 AM
brochure printing,online yearbook,printing,books printing,publishing elie Computer Support 0 08-18-2007 10:11 AM
'Procedure or function <stored procedure name> has too many arguments specified',,,ARGH! Mike P ASP .Net 0 06-19-2006 01:19 PM
1. Ruby result: 101 seconds , 2. Java result:9.8 seconds, 3. Perl result:62 seconds Michael Tan Ruby 32 07-21-2005 03:23 PM
How to call parameterized stored procedure to return result set? Lacka ASP .Net 2 12-31-2004 03:39 PM



Advertisments