Why use dollar sign $ for variables

[Dennis Walter]

Hello Perl-Experts,

we were just wondering (in our project room where there is no
sunlight...) why successful 'modern' programming languages like perl and
php need this ugly $-sign in front of (nearly) every variable name.

Is this really just because it makes parsing of program text easier? I
mean, then, after some time, some capable hacker should have volunteered
for improving the parser, shouldn't he?


Thanks for your answers

D.

 

[Peter Hickman]

Hello Perl-Experts,

we were just wondering (in our project room where there is no
sunlight...) why successful 'modern' programming languages like perl and
php need this ugly $-sign in front of (nearly) every variable name.

Is this really just because it makes parsing of program text easier? I
mean, then, after some time, some capable hacker should have volunteered
for improving the parser, shouldn't he?


Thanks for your answers

D.

The $ symbol is not used to indicate a variable as such but the type of the
variable $ = scalar, @ = array, % = hash, & = code and \ = reference. It can get
a little more complicated than that but it will do for starters.

I would have certainly helped witting the earlier parsers, Perl 4 is easily
identified from it's use of the & before subroutines, but I'm not sure that that
would be a valid argument now, but it certainly help with syntax highlighting!

As to 'fixing' it, just imagine the number of programs that would break.

 

[Richard Gration]

Hello Perl-Experts,
we were just wondering (in our project room where there is no
sunlight...) why successful 'modern' programming languages like perl and
php need this ugly $-sign in front of (nearly) every variable name. Is
this really just because it makes parsing of program text easier? I
mean, then, after some time, some capable hacker should have volunteered
for improving the parser, shouldn't he? Thanks for your answers
D.

Hmm. I was wondering the other day about those ugly 'int i' declaration
statements in 'ancient' programming languages like C. Is this really just
because it makes parsing of program text easier? I mean, then, after some
time, some capable hacker should have volunteered for improving the
parser, shouldn't he?

;-)

I've never studied CS, so I'm not aware of any formal requirements for
language design which might mandate variable typing, but I do know that
it helps in the practice of programming. Once you accept that, then how
you type those variables is an aesthetic choice. The '$', '@', '%', etc
signs on perl variables don't look ugly to me. In fact my parser (the one
in my head) likes them quite a lot, and would be sorry to see them go!

Programming languages in general go out of their way to help you help
yourself and variable typing is one of those ways, however it's done.

Rich

PS There is at least one handy side-effect, as in

$count = @lines;

 

[David H. Adler]

One reason is so you can have variables like:

$chomp
@print
%foreach

without having to memorize (and avoid using) a few hundred reserved words.

Not to mention that you can have these sets of variables:

$chomp, @chomp, %chomp
$print, @print, %print
$foreach @foreach %foreach

Although that is probably rarely a good idea.

dha

 

[Dale Henderson]

DHA> Not to mention that you can have these sets of variables:

DHA> $chomp, @chomp, %chomp
DHA> $print, @print, %print
DHA> $foreach @foreach %foreach

DHA> Although that is probably rarely a good idea.

DHA> dha

I often use constructs like

foreach $color (@color){...}

 

[Bob Walton]

Dennis Walter wrote:

....

we were just wondering (in our project room where there is no
sunlight...) why successful 'modern' programming languages like perl and
php need this ugly $-sign in front of (nearly) every variable name.

Is this really just because it makes parsing of program text easier? I
mean, then, after some time, some capable hacker should have volunteered
for improving the parser, shouldn't he?

Well, one very helpful usage it provides is variable interpolation in
strings:

print "Value of var = $var\n";

for example. I have also heard that it makes the parser much faster,
but I forget where I heard that.

....

 

[Keith Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DHA> Not to mention that you can have these sets of variables:

DHA> $chomp, @chomp, %chomp
DHA> $print, @print, %print
DHA> $foreach @foreach %foreach

DHA> Although that is probably rarely a good idea.

I often use constructs like

foreach $color (@color){...}

Yes, but do you do

print push @chomp,chomp $print{$foreach} foreach $foreach (keys %print);

? ;-)

I can just imagine Perl 7: all variables must be reserved words.

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFA61qZhVcNCxZ5ID8RAiJJAKCbN/uHiYJ6+fZT+ojCgB5HilQ8OwCgh0Tl
nofFIt2Nv9apWd9rlc5WApc=
=8kRM
-----END PGP SIGNATURE-----

 

[Ramon F Herrera]

Hmm. I was wondering the other day about those ugly 'int i' declaration
statements in 'ancient' programming languages like C. Is this really just
because it makes parsing of program text easier? I mean, then, after some
time, some capable hacker should have volunteered for improving the
parser, shouldn't he?

;-)

Let's not forget an important difference between C and Perl.
One is compiled, and compilation can take as long as necessary.
Being interpreted, Perl has to parse souce code and catch errors
on the fly at the same time as it executes valid code, as fast
as possible.

That issue probably affected Larry Wall's choice of prepending
variables with $, %, &, etc.

-Ramon

 

[David H. Adler]

Ok, maybe 'rare' was the wrong choice of words...

Yes, but do you do

print push @chomp,chomp $print{$foreach} foreach $foreach (keys %print);

Now, *that* would be a bad idea.

I can just imagine Perl 7: all variables must be reserved words.

I feel obliged to give my advice, being someone who made a completely
insane suggestion while drinking at a perl conference, only to later
find that someone had evolved it into an actual perl 6 rfc:

DO NOT GIVE THEM IDEAS.

1/2

dha

 

[Dave Cross]

Let's not forget an important difference between C and Perl.
One is compiled, and compilation can take as long as necessary.
Being interpreted, Perl has to parse souce code and catch errors
on the fly at the same time as it executes valid code, as fast
as possible.

Perl isn't interpreted, it's compiled. Sure it's compiled each time you
run your program, but it's still compiled. Not interpreted.

Dave...

 

[Tassilo v. Parseval]

Also sprach Richard Gration:

Hmm. I was wondering the other day about those ugly 'int i' declaration
statements in 'ancient' programming languages like C. Is this really just
because it makes parsing of program text easier? I mean, then, after some
time, some capable hacker should have volunteered for improving the
parser, shouldn't he?

The need for declaring variables in certain languages does not have
syntactic reasons. In fact, a context free grammar is not expressive
enough to handle this at all. Dealing with the type of a variable
happens at a later stage (when figuring out the semantics of a program).

Languages requiring you to declare variables and giving them a type are
called statically typed languages. One advantage is that certain errors
can be detected at compile time. Another one is that it is possible to
use those type information to optimize the resulting executable (for
speed and/or for memory consumption).

Perl6 will have optional types on variables for both of the above
reasons.

Tassilo

 

[Bill]

Perl isn't interpreted, it's compiled. Sure it's compiled each time you
run your program, but it's still compiled. Not interpreted.

Mere semantics. See:

http://groups.google.com/[email protected]&output=gplain

--hth

 

[Joe Smith]

Let's not forget an important difference between C and Perl.
One is compiled, and compilation can take as long as necessary.
Being interpreted, Perl has to parse souce code and catch errors
on the fly at the same time as it executes valid code, as fast
as possible.

Unlike /bin/sh, bash, tcsh, etc, perl does not interpret (parse and
execute) the script a line at a time as you implied.

In the absence of any 'use' statements or BEGIN{} blocks, perl parses
the entire program before executing any code. It does this every time
the perl script is invoked, vaguely like an interpreter, but perl
definitely has a compile phase and a run phase.
-Joe

 

[Michele Dondi]

we were just wondering (in our project room where there is no
sunlight...) why successful 'modern' programming languages like perl and
php need this ugly $-sign in front of (nearly) every variable name.

Because beauty and ugliness are by far a subjective matter.

I have had some exposure to various programming languages, but for for
a series of reasons now I'm routinely using only Perl. Well, when I
happen to stumble onto snippets of code from other languages,
including very "common" ones like C/C++ or Java, my instinctive
reaction is "Hey, where are $'s, @'s and %'s?!?"

Also, they mark very clearly the different syntactic/semantic
behaviour of different kinds variables in agreement with the natural
languages principles that are so pervasive in Perl, just like
different suffixes help to tell e.g. verbs from nouns in many actual
natural languages.

Well, (a very different!) Perl could have lived also without "those
signs", and they are there probably because of historic reasons, but
they are there and they have proved efficient and useful, so I doubt
that even in a remote future they will be phased out, even if starting
with Perl6 their semantic will slightly change...

BTW: as far as php is concerned, I think that the answer is: because
to some extent it's simply an extremely stripped down Perl designed
for a limited range of uses. (There's been a lenghty -and insightful!-
discussion here as to wether it's actually a programming language at
all effects or not.)


Michele
--
#!/usr/bin/perl -lp
BEGIN{*ARGV=do{open $_,q,<,,\$/;$_}}s z^z seek DATA,11,$[;($,
=ucfirst<DATA>)=~s x .*x q^~ZEX69l^^q,^2$;][@,xe.$, zex,s e1e
q 1~BEER XX1^q~4761rA67thb ~eex ,s aba m,P..,,substr$&,$.,age
__END__

 

[Rene Nyffenegger]

Unlike /bin/sh, bash, tcsh, etc, perl does not interpret (parse and

execute) the script a line at a time as you implied.

In the absence of any 'use' statements or BEGIN{} blocks, perl parses
the entire program before executing any code. It does this every time
the perl script is invoked, vaguely like an interpreter, but perl
definitely has a compile phase and a run phase.
-Joe

Just out of curiosity: would it be possible to store the compiled/parsed
script away and load it later so that a script doesn't have to be
compiled again if it hasn't changed?

Rene

 

[John Bokma]

Perl isn't interpreted, it's compiled. Sure it's compiled each time you
run your program, but it's still compiled. Not interpreted.

Of course it's interpreted :-D

 

[John Bokma]

Unlike /bin/sh, bash, tcsh, etc, perl does not interpret (parse and
execute) the script a line at a time as you implied.

In the absence of any 'use' statements or BEGIN{} blocks, perl parses
the entire program before executing any code. It does this every time
the perl script is invoked, vaguely like an interpreter, but perl
definitely has a compile phase and a run phase.

Even interpreted BBC Basic (IIRC) had that. Constant folding and some
other optimizations IIRC, but I still call it an interpreter :-D.

 

[John Bokma]

Just out of curiosity: would it be possible to store the compiled/parsed
script away and load it later so that a script doesn't have to be
compiled again if it hasn't changed?

IIRC; yes, have a look at the B modules.

 

[vali]

DHA> Not to mention that you can have these sets of variables:

DHA> $chomp, @chomp, %chomp
DHA> $print, @print, %print
DHA> $foreach @foreach %foreach

DHA> Although that is probably rarely a good idea.

DHA> dha

I often use constructs like

foreach $color (@color){...}

or maybe even better:
foreach $color (@colors){...}
^
__Vali

 

[Charlton Wilbur]

MD> I have had some exposure to various programming languages, but
MD> for for a series of reasons now I'm routinely using only
MD> Perl. Well, when I happen to stumble onto snippets of code
MD> from other languages, including very "common" ones like C/C++
MD> or Java, my instinctive reaction is "Hey, where are $'s, @'s
MD> and %'s?!?"

MD> Also, they mark very clearly the different syntactic/semantic
MD> behaviour of different kinds variables in agreement with the
MD> natural languages principles that are so pervasive in Perl,
MD> just like different suffixes help to tell e.g. verbs from
MD> nouns in many actual natural languages.

I think part of this has to do with the expressiveness of Perl as
well. I'm using Perl, C, and Objective-C fairly equally nowadays, and
it seems to me that C and Objective-C have far fewer constructs and
far fewer keywords -- and as a result, it's much easier to spot the
variables. By contrast, Perl, which has a far wider variety of legal
constructs, a far wider variety of reserved words, and a lot of
flexibility within those constructs and with those words, uses sigils
to set off variables because it makes things easier for humans to
understand.

Or, stated another way, most of the power of Objective-C is in the
libraries, and the language is pretty much just the glue that holds
the library calls together. Much of the power of Perl is in the core
language. Because of this, any tool such as sigils on variables that
makes Perl code easier for humans to parse and understand --
regardless of the ease with which computers may parse and understand
it -- is useful.

Charlton