In particular, the special ${^_XYZ} variables are always taken to be in package main, regardless of any package declarations presently in scope.

Note that this paragraph should be read as the last paragraph of the whole section "The Syntax of Variable Names ", as it provides additional information to important details in the preceding text. It definitely doesn't mean "If you want to introduce a global variable without a declaration, start its name with ^_!".

Hmm ... I've never seen anyone introducing ${^_globals} in his code.

Probably because it's much easier and clearer to just use a namespace for $MyApp::globals ...

But well this might be useful for machine translations, that's also why JS originally allowed the $ symbol anywhere in variable identifiers.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

if you preface a scalar variable name with an underscore it will by default be in the main

Dave.

You are well read and astute. The text did not say that exactly but I inferred it from the following text:

Perl identifiers that begin with digits or punctuation characters are 
+exempt from the effects of the package declaration and are always for
+ced to be in package main
[download]

So the question that left me with was, 'what exactly is considered a punctuation character?'

The history of the underscore has a lot to do with typewriters -- it was apparently the key people used to use to underscore words. However, that history is irrelevant to how we use it today. When I visit thesaurus.com:

Punctuation is the act or system of using specific marks or symbols in
+ writing to separate different elements from each other or to make wr
+iting more clear.
[download]

My use, and the question, was in line with this definition. I've seen people use underscores in method names to tell others that 'this method is private -- do not use it.' So the question is perfectly valid -- how does one do the same thing with a variable? I figured I would try an underscore and I got a weird behavior.

Celebrate Intellectual Diversity

So the question that left me with was, 'what exactly is considered a punctuation character?'

The first two paragraphs of perlvar say, in part:

Variable names in Perl can have several formats.  Usually, they
must begin with a letter or underscore ...
[download]

Perl variable names may also be a sequence of digits, a single
punctuation character, or ...
[download]

I think its unambiguous from that opening that an underscore is grouped with letters rather than punctuation characters.

Dave.

I'd say punctuation characters are those you can use in place of a point.°

So . , ; : ! ? ¿ etc...

Anyway I think this phrasing is lacking perlvar lists some special variables which are not punctuation but global, like $@ or %INC

Update

So that's the definition I found online, wider than I thought but clearly not covering @

Punctuation characters are symbols used in writing to clarify meaning and indicate pauses or stops. The 14 primary punctuation marks in English include the period, comma, question mark, exclamation point, colon, semicolon, dash, hyphen, parentheses, brackets, braces, apostrophe, quotation marks, and ellipsis.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

°) "Punkt" is point in German, so it may be more obvious for me, "point" is most probably a French "mutant" of a Latin word like "punctum"

if you preface a scalar variable name with an underscore it will by default be in the main package

If you preface a variable name with an apostrophe ($'var) or two colons ($::var) it WILL be in the main package.

As an aside I should mention why I keep posting these cryptic things about basic Perl functionality. I am researching why people run into problems with Perl and give up. The target audience (for now) includes project management and product owners who have enough familiarity with the language to recommend its use but want to simultaneously reduce the backlash that might come from doing so.

I've written a lot of nodes related to this topic over the years. I hope you find some ideas from the nodes listed below to help you sell Perl to your project management and product owners.

• Re: Some Help for a Report About Perl (Readability vs Maintainability References)
• On Coding Standards and Code Reviews
• Unix shell versus Perl
• Why Create Coding Standards and Perform Code Reviews?
• Re: I need perl coding standards (Coding Standards References)

👁️🍾👍🦟

You should probably start a new thread for this.

My number one guess of frustration would be (de)referencing rules with sigils.

(The deeper reason is the transition from Perl4 to 5 and trying to piggy back new features while retaining almost full compatibility)

Update

For instance take pushing to a AoHoA passed as reference $arr

Compare Perl

• push @{ $arr->[0]{key} }, "foo";

• arr[0]["key"].push("foo");

My research involves scanning job lists for companies asking for help with Perl and drilling down into the company information to identify the nature of their need. Special attention is given to companies that indicate that they are switching away from Perl to another language. At that point I try and contact developers 'in the know' for what problems they experienced with Perl and perhaps get a reason for the change.

What I am finding is that developers inherit the codebase from others that have left the position. They claim to try and learn the language and run into roadblocks. No one thus far has claimed that the sigils was too hard for them to understand. What I am hearing is a lot about classes.

Celebrate Intellectual Diversity

I didn't mean sigils as such but the whole duality of arrays and array_refs and the resulting grammatical overhead.

For instance:

If $arr was always an alias of \@arr and vice versa, you'd still have sigils but way less headache.

> What I am hearing is a lot about classes

I can imagine that, because Perl has a zoo of OO models.

But I think most people already get frustrated at dereferencing before reaching OO.

YMMV

Anyway, I'd love to have one of those mission "impossible" legacy projects, just to prove what a real expert can achieve by cleaning it up.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}