what is actually stored in $a[$i]? Is it the string "123" or the number 123.0?

split returns strings.

And does it make any difference to the perl programmer?

No. It works as intended in practically all cases.

The only time I can think of where it makes a difference is when you use |, & or ^ on it with a string as the other operand.

I'm using the results entirely in numerical calculations, so I want to do all conversion of string-to-number (if any) at the time I read the file and get it over with early.

It's not needed, but you could use

my @nums = map 0+$_, split /,/;
[download]

I've been using the perl debugger to print these variables but I can't (yet) tell whether it's printing a string or a number.

That just shows you how much it matters.

Devel::Peek will show you. pPOK = string, pIOK, pUOK or pNOK = number. Can be both.

>perl -e"use Devel::Peek; my $x=123; Dump($x);"
SV = IV(0x1826628) at 0x225350
  REFCNT = 1
  FLAGS = (PADBUSY,PADMY,IOK,pIOK)           <-- signed int
  IV = 123

>perl -e"use Devel::Peek; my $x='123'; Dump($x);"
SV = PV(0x226154) at 0x225350
  REFCNT = 1
  FLAGS = (PADBUSY,PADMY,POK,pPOK)           <-- string
  PV = 0x18227c4 "123"\0
  CUR = 3
  LEN = 4

>perl -e"use Devel::Peek; my $x=123; qq{$x}; Dump($x);"
SV = PVIV(0x22718c) at 0x225358
  REFCNT = 1
  FLAGS = (PADBUSY,PADMY,IOK,POK,pIOK,pPOK)  <-- signed int AND string
  IV = 123
  PV = 0x18227cc "123"\0
  CUR = 3
  LEN = 4
[download]

what is actually stored in $a$i? Is it the string "123" or the number 123.0? And does it make any difference to the perl programmer?

If it does matter to you - for instance, if you need numbers to have a specific format - you can explicitly convert them to strings using something like sprintf().

Let's say that my use of $x is inside a loop and complicated, like $y = $x**$x or somesuch, and also prints $y and $x to the console.

I'm assuming (and hoping) that perl is smart enough to convert $x to a number for the computations and to a string for printing, and do it all at compile time and not at runtime. Is this a safe assumption?

Perl will definitely treat $x and$y as numbers for the computations, and when you print $x and $y you will be presented with their current numeric values. If that's what you're after (and I assume it is) then you have nothing to worry about. But if, for some perverse reason, you want the following to print $y's string value (2) instead of its numeric value (7) then you're out of luck:

use warnings;

$y = "2";
$y += 5;

print $y;
[download]

Btw, it's all being taken care of quite efficiently at runtime - not compile time. I wouldn't worry about wasting cycles - this is the way it's designed to work. Just let perl handle it.

As mentioned elsewhere in this thread, doing repeated Devel::Peek::Dump($x) is the best way of seeing how perl keeps track of things by using the scalar's flags and (PV,IV,UV,NV) slots.

Cheers,
Rob

Consider:

my $str = '123';
$str += 10;
print "str = /$str/\n";

my $num = 456;
$num =~ s/6/8/;
print "num = /$num/\n";
[download]

Output:

str = /133/
num = /458/
[download]

I agree with the other monks. Except in some rare circumstances, Perl will do the right thing with your strings at the point that you treat them as numbers.

There's one rare circumstance I haven't seen mentioned however. I ran across it a while ago and wrote about it in Strings and numbers: losing memory and mind. The short version is that if you read the number as a string and then convert it later, it will take up (a little bit) more memory than if you'd converted it immediately upon reading it. Since the extra memory used is so small, the rare circumstance that this makes a difference is when you have millions of stings being treated as numbers. Failing that, this is nothing to worry about.

I rather feel this is an advantage: how a scalar behaves is determined by the context in which it is used. Usually, Perl makes just the right choice and you are spared of having to enforce a special interpretation. Do you have an example of a case where a scalar was not interpreted as you expected?

No, not yet. My first perl program actually works as expected :) Just concerned about wasting CPU cycles, is all.

My first exposure to OO programming was Actor, a commercial implementation of smalltalk, which I really liked a lot except for how slow it was. To add 2+2, the number 2 had to send a message to 2 telling it to add itself to 2. Ever since I've fretted about concepts like 'early binding' and useless conversions of formats inside loops and such.

I should say I'm astonished at the speed and depth of all the replies to my newbie question and I'm very grateful to all of you. That's the best help in the shortest time I've ever seen, and I've learned good stuff from every reply. Thanks!

See perlguts for more than you probably ever want to know. Under the hood an ordinary Scalar Value (SV) can be any one or more of an integer value (IV), a double (NV), a string (PV), and another scalar (SV). Conversions are made on demand so if you use a string as a number it gets converted to a number at that stage. If you only use it as a string it stays as a string. The bottom line is that part of the beauty of Perl is that you don't have to worry about the nitty gritty.

You could consider the contents of a Perl scalar to be a quantum superposition of string and numeric states which are resolved when you look at them. :-)

But unlike real quanta, reading a Perl variable doesn't force it to collapse into only one state.

To make this more concrete, note that converting a number (either integer or floating point) to a string leaves both the numeric AND string values marked as valid:

$ perl -MDevel::Peek -wle '$x=12345; print Dump $x; print "$x"; print 
+Dump $x'
SV = IV(0x1004f958) at 0x1004f958
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 12345

12345
SV = PVIV(0x10023810) at 0x1004f958
  REFCNT = 1
  FLAGS = (IOK,POK,pIOK,pPOK)
  IV = 12345
  PV = 0x10040c08 "12345"\0
  CUR = 5
  LEN = 8
[download]

The same thing works for string to numeric conversions, so

$x="12345.67"; $y=$x+1;
[download]

leaves $x with a floating point value and a string value which are both valid.

Not only is the Perl implementation Doing What I Mean, by caching the results before it even occurs to me that it would be a good idea it's Doing What I Should Have Meant!

I'm reading a comma-separated-value ascii text file containing numerical data, e.g. "123,234,456" on each line.

I'm using 'split' to separate the fields of each line

Don't do that. Use Text::CSV_XS. CSV files will bite you if you're not careful.

Is it the string "123" or the number 123.0? And does it make any difference to the perl programmer?

It's a scalar. Don't worry about how it's stored under the hood, it will be a string or an integer or a float when you need it to be one of those things.

Under the hood, since you're using split, you'll be getting strings. But:

my $line = '123,456,789';
my ($val) = split(',' , $line);  # $val is the string '123'
$val += 2;                       # $val is now the integer 125
$val /= 2;                       # $val is now the float 62.5
print "I ended up with $val"     # $val is treated as the string '62.5
+'
[download]

The whole point of Perl's weak typing is that you don't have to worry about this sort of thing. If you want to validate that your scalar contains a certain type of data (not under the hood, mind you), check out Data::Validate.