return multiple arrays from functions

[Ross Clement]

Hi. Does anyone have any hints as to the best way to return multiple
arrays from a function? Normally, being a rather object oriented kinda
guy, I use objects for most data, making return from a function easy.
But, sometimes I just want to get the job done quickly, and prefer to
return arrays.

What I'm trying right now (i.e., I haven't fully tested this yet) is
the following:

# define the function as:

sub func
{
my %hash = ();
my @arr = ();

# etc etc etc

return (\%hash, \@arr );
}

# and then have the calling code is:

($myhash, $myarr) = &func();

Any hints for better ways to do this?

Cheers,

Ross-c

 

[Tore Aursand]

Hi. Does anyone have any hints as to the best way to return multiple
arrays from a function?
[...]

What I'm trying right now (i.e., I haven't fully tested this yet) is
the following:

# define the function as:

sub func
{
my %hash = ();
my @arr = ();

# etc etc etc

return (\%hash, \@arr );
}

# and then have the calling code is:

($myhash, $myarr) = &func();

Any hints for better ways to do this?

What's the problem with this, except that you don't want to call your
function with a '&'?

 

[Ross Clement]

What's the problem with this, except that you don't want to call your
function with a '&'?

No problem that I know of, just wondering if there was a better way.

Cheers,

Ross-c

 

[Tore Aursand]

No problem that I know of, just wondering if there was a better way.

It would be truly interesting to hear from you what you mean would be a
better way? I can't think of a better way;

my ( $array, $hash ) = foo();

sub foo {
my @array = ();
my %hash = ();

return ( \@array, \%hash );
}

Do you?

 

[Ross Clement]

What's the problem with this, except that you don't want to call your
function with a '&'?

PS: About using '&' for function calls, I originally learnt Perl (some
years ago) from Nik Silver's Perl Tutorial. It uses '&' to mark
subroutine calls. While I'm aware that missing out the '&' doesn't
seem to cause problems, I usually put it in there. Is there a reason
why I shouldn't?

The relevant page from Nik's perl tutorial is:

http://www.comp.leeds.ac.uk/nik/subroutines.html

Cheers,

Ross-c

 

[Gunnar Hjalmarsson]

PS: About using '&' for function calls, I originally learnt Perl
(some years ago) from Nik Silver's Perl Tutorial. It uses '&' to
mark subroutine calls.

That was how you did it in Perl 4.

While I'm aware that missing out the '&' doesn't seem to cause
problems, I usually put it in there. Is there a reason why I
shouldn't?

Yes. Even if it doesn't normally cause problems, just that can happen,
since calling a subroutine in Perl 5 with the leading '&' changes the
behaviour of the subroutine in a couple of respects. Unless you are
aware of the difference, and the 'other' behaviour is what you
actually want, you should skip the '&'.

See http://www.perldoc.com/perl5.8.0/pod/perlsub.html

 

[Tassilo v. Parseval]

Also sprach Ross Clement:

PS: About using '&' for function calls, I originally learnt Perl (some
years ago) from Nik Silver's Perl Tutorial. It uses '&' to mark
subroutine calls. While I'm aware that missing out the '&' doesn't
seem to cause problems, I usually put it in there. Is there a reason
why I shouldn't?

The relevant page from Nik's perl tutorial is:

http://www.comp.leeds.ac.uk/nik/subroutines.html

This tutorial appears to be a little Perl4-ish. Note the use of local()
in a way that is really no longer state-of-the-art.

Other than that, the topic of ampersands in Perl5 is a little
controversial. It has two side-effects. One is that any potential
prototype of a function is ignored. Prototypes are of limited usefulness
and aren't employed that often because of it.

The other thing that happens is that the current @_ is implicitely
passed on to the function if it was called with no arguments:

sub foo { print "In foo: @_\n" }
@_ = qw/a b c/;
&foo;
__END__
In foo: a b c

Note that this does not happen when you call it with '&foo()'.

Both of these side-effects are overestimated IMO. If someone finds that
using the ampersand on function calls adds some visual clarity to his
source or whatever, then he can certainly use it. It should not harm the
correctness of his program.

Tassilo

 

[gnari]

PS: About using '&' for function calls, I originally learnt Perl (some
years ago) from Nik Silver's Perl Tutorial. It uses '&' to mark
subroutine calls. While I'm aware that missing out the '&' doesn't
seem to cause problems, I usually put it in there. Is there a reason
why I shouldn't?

if you read the docs
perldoc perlsub
you will see that
&func;
&func();
func;
func();
all work is subtly different ways.

the safe thing is to use func() unless you know what the side effects are,
and want them.

the &func() form is usually a sign of a programmer that has not
read the docs.

gnari

 

[thumb_42]

the &func() form is usually a sign of a programmer that has not
read the docs.

I generally happen to *like* &func() in part because it's what I've always
used. (The other reason is that it makes it a little more obvious that I'm
calling a subroutine and not a method or perl builtin)

Jamie

 

[Uri Guttman]

t4> I generally happen to *like* &func() in part because it's what
t4> I've always used. (The other reason is that it makes it a little
t4> more obvious that I'm calling a subroutine and not a method or
t4> perl builtin)

and it makes your code look like a perl4 kiddie coder wrote it. just
because you are used to it doesn't defend your use of it. and how can it
be confused with a method? there is NO object nor -> there. and
confusing it with a perl function is rare since you should KNOW most of
the perl function names and not use a sub name that would be confused
with them.

any more weak defenses?

uri

 

[Tassilo v. Parseval]

Also sprach Uri Guttman:

t4> I generally happen to *like* &func() in part because it's what
t4> I've always used. (The other reason is that it makes it a little
t4> more obvious that I'm calling a subroutine and not a method or
t4> perl builtin)

and it makes your code look like a perl4 kiddie coder wrote it. just
because you are used to it doesn't defend your use of it. and how can it
be confused with a method? there is NO object nor -> there. and
confusing it with a perl function is rare since you should KNOW most of
the perl function names and not use a sub name that would be confused
with them.

any more weak defenses?

Consistency. Look at how you create references for instance:

*GLOB => \*GLOB
$scalar => \$scalar
@ary => \@ary
%hash => \%hash

When using the ampersand, this table can be completed to

&func => \&func

Every data-type (and functions in Perl can be considered a type as well)
has a special sigil so why not keep using it with functions, too? Not
that I'd be using ampersands on function calls, but then I don't see a
problem when others do.

It's a style issue and not a technical one (the often quoted
side-effects of the ampersand really don't count since they wont get
into the way). And now that we are talking about matters of taste, the
old Latin saying "De gustibus non est disputandum" comes to my mind.

Tassilo

 

[Ross Clement]

It would be truly interesting to hear from you what you mean would be a
better way? I can't think of a better way;

Erm, no I can't think of a better way.

But, I don't know everything there is to know about Perl.

If I already knew of a better way, then there wouldn't have been any
point in my posting the question to the group.

Cheers,

Ross-c

 

[Uri Guttman]

TvP> Also sprach Uri Guttman:

TvP> Consistency. Look at how you create references for instance:

TvP> *GLOB => \*GLOB
TvP> $scalar => \$scalar
TvP> @ary => \@ary
TvP> %hash => \%hash

TvP> When using the ampersand, this table can be completed to

TvP> &func => \&func

funcs are usually called with arguments and need () (i don't use the
operator style with no () since that needs predeclaring). so the case of
no arguments is just foo(). that is enough to mark a func to me and the
& is just more unneeded noise. other than dispatch tables and a few
other places where you need code refs, & doesn't come in to play
(especially for most newbies) so this is not a strong point IMO.

TvP> Every data-type (and functions in Perl can be considered a type
TvP> as well) has a special sigil so why not keep using it with
TvP> functions, too? Not that I'd be using ampersands on function
TvP> calls, but then I don't see a problem when others do.

TvP> It's a style issue and not a technical one (the often quoted
TvP> side-effects of the ampersand really don't count since they wont
TvP> get into the way). And now that we are talking about matters of
TvP> taste, the old Latin saying "De gustibus non est disputandum"
TvP> comes to my mind.

it will bite them at some point with passing @_ implicitly or disabling
prototypes. it is doing something without the code understanding why so
it is more than just style. and i covered the noisy style point above as
well.

uri