use strict;
use warnings;


my $test = foo();

print $test."\n";

sub foo
{
        return "Hello World!";
}
[download]

1) Is this were "my" comes in? What about "local?" What's the difference? I understand local went out with the goto statement. True?

To explain the differences, there would have to similarities.

my creates a lexically scoped variable.

local temporarily saves a package variable, array element or hash element. The previous value of the variable will be restored when the current scope is exited.

2) How do I return a value from a sub to main, if Perl doesn't have a return statement?

By using the return statement or by evaluating the value to return as the last statement of the sub.

sub f { ...; return $x + 1 }
sub f { ...; $x + 1 }
[download]

Why not show some of the code you've done so far? Don't worry about it if you think it's really bad — that's why you came here right? :)

A few tutorials here:
• Variable Scoping in Perl: the basics
• Lexical scoping like a fox

From the perldocs:
• perlintro - scroll down to the section 'Perl Variable Types'

You've been given some good answers already but it's not a bad idea to get more familiar with the site's tutorials and the perldocs.

1) yes, this is where my* comes in.
2) you could read the perlsub man page and search for the word return and be pleased to know that perl subs return a value. You get to choose which one.
The perlsub page really is a good starting point.

Edit * for the scope of your question and the assumed use case. See other response for helpful scoping tutorials.

You are right to be unimpressed with your text book! "Modern" Perl provides very good management of variable locality and you almost never need to use global variables. There are very good reasons for not using globalvariables if they can be avoided. Related to this is the mantra: always use strictures (use strict; use warnings;), which helps avoid some of the worst aspects of old school Perl variables ("package" variables) by forcing you to use "lexical" variables. That doesn't prevent you introducing global lexical variables however, that is something you have to dicipline yourself against.

local provides a way of reusing a (generally) package variable in a local (runtime) scope. my creates a new instance of a variable in a lexical scope (generally up to the enclosing } or end of the file). local still has valid uses, but unless you need local's special proerties, my is what you should go for.

1. my, local (goto)
2. return

I understand local went out with the goto statement. True?

2) use my to scope all variables; limit scope to smallest practical enclosing block

3)

use strict;
use warnings;
[download]

4) Get a copy of "The Camel" (Programming Perl, 3e); if you're completely new to programming you may find Learning Perl helpful too.

5) There is a return statement, see references in #4

-Greg

my $var = foo();

sub foo
  {
    return 'bar';
  }

print $var;
[download]

my $var = foo('some_text_for_instance');


sub foo
   {
    my $text = $_[0];

    return 'bar';
   }
[download]

my $var = foo($somevar,"some text",$somehashref);

sub foo
  {
   my $variable = $_[0];
   my $text = $_[1];
   my $hashref = $_[2];


   return $hashref->{'some_key'};
  }
[download]

 
sub foo
  {
   my @private_local_array = @_;

   #then lets return element 5 for some reason

   return $private_local_array[4];
  }
[download]

my @digitsOfPi = (3,1,4,1,5,9,2,6,5,3,5,9,'etc');
frobnicate('foo', 'bar', @digitsOfPi);

sub frobnicate
{
  my $fooString = shift;
  my $barString = shift @_;  #more typing
  my @remainder = @_;
  print $remainder[0] == 3 ? 'yum' :'eew';
}
[download]

my (...) = @_; is a very common way of getting args. I can't believe it wasn't mentioned.

sub frobnicate {
   my ($foo, $bar, @remainder) = @_;
   print $remainder[0] == 3 ? 'yum' :'eew';
}
[download]

I understand local went out with the goto statement. True?

    local $Opt{debug} = 1;
    some_function();
[download]

It is in just such sitations that local shines. Here’s another:

    local $SIG{INT} = "IGNORE";
[download]

And another:

    @paragraphs = do { local $/ = q(); <FH> };
[download]

This is one of my favorite reasons for using Perl “objects.”   The standard way of doing this in Perl might not conform to anyone’s college textbook, but it nevertheless is quite practical.   An object is basically “a blessed hash,” and as such it contains both code and data in one convenient, self-ecapsulated “thing.”   Each instance of an object neatly stands by itself, with easy access to “its” data.   Variables declared within the package are naturally shielded from anyone outside.   And so on.   It is a pragmatic solution to issues kind-of like the ones you are considering now ... and never mind your college textbook, anyway.

How are mentioning advanced topics like 'bless' and 'package' in a thread where the OP is not even familiar with some of the basic concepts of Perl helpful? Or pragmatic for that matter? I admire your enthusiasm to help, but please think about the knowledge level of the people you are trying to help when posting!

Elda Taluta; Sarks Sark; Ark Arks

/me nods...

I certainly do not mean to “shoot over the head of” anyone, let alone purposefully.   But even if every technical detail of what I outlined (inadvertantly...) is too esoteric, I hope that the essential notion is both useful and clear, and relevant.

local, as has been said, makes special use of a global or package variable. Whereas it may be unusual to use it for ordinary variables, given that my is sufficient for this purpose, it comes into its own for built-in variables. For example, if a subroutine uses $_, it can ensure preservation of the callers value for $_, simply by declaring local $_, whereas my $_ just won't be allowed, even without the strict or warning pragmas. So local is absolutely necessary for this and is almost a sine qua non if one wants to use $_ in a module method without "hurting" any possible caller.

The argument about goto was best explained by Kathleen Jensen in the 1970s in the definitive Pascal book known to most as "Jensen and Wirth". The arguments therein apply to Perl as much as any "block structured" language, that is to say, whereas block structure might technically obviate the need for goto, it remains justified and even encouraged (by me at least) for the special case of breaking out of structure on encountering an exception. For example:-

sub fred {
    my $self = shift;
    $self -> parse
      or goto SORRYFRED;
    while ( $self -> codegen ) {
        $self -> codeprint
          or goto SORRYFRED;
    }
    return 1;
SORRYFRED:
    print STDERR $self -> formatmsg;
    $self -> { SEVERITY } < 2
      or $self -> cexit; # case of fatal
    0; # case of warning
}
[download]

Finally, if you don't want to return explicitly, the value of the statement of the routine will get returned to the caller anyway, so in the above example, there are two explicit returns (update: actually I mean an explicit return and a call to an exit routine to manage exit codes for example) and the final way out at the last line is just a 0; to return 0 to the caller.