# Mathematical Abstraction corresponding to References

Discussion in 'Perl Misc' started by poopdeville@gmail.com, Oct 11, 2005.

1. ### Guest

Hi everybody,

I'm a mathematician who's trying to learn Perl. My knowledge has been
steadily growing, even though I don't have a computer science
background. I rely on my familiarity with the mathematical
abstractions of computation (such as Turing machines and recursive
functions) to figure out the "essential" semantics of code.

I want to understand references, but I've gone through the relevant
chapter in "Programming Perl" and have just gone cross-eyed. Can
someone point (heh) me to a good resource? Preferably one that relates
the pointer/references paradigm to a mathematical abstraction of
computation.

It seems almost as if you comp.sci guys are making distinctions about
variables we math guys don't. Something along the lines of "x" is the
name of the variable x, whose value is (currently) a fixed constant.
If this is the right idea, how is this useful in a computational
context?

Thanks!
'cid 'ooh

, Oct 11, 2005

2. ### Paul LalliGuest

wrote:
> I'm a mathematician who's trying to learn Perl. My knowledge has been
> steadily growing, even though I don't have a computer science
> background. I rely on my familiarity with the mathematical
> abstractions of computation (such as Turing machines and recursive
> functions) to figure out the "essential" semantics of code.
>
> I want to understand references, but I've gone through the relevant
> chapter in "Programming Perl" and have just gone cross-eyed. Can
> someone point (heh) me to a good resource?

perldoc perlreftut
perldoc perlref
perldoc perlrefref

> Preferably one that relates
> the pointer/references paradigm to a mathematical abstraction of
> computation.

Pointers are not a concept that have much meaning in Perl. Perhaps you
are thinking of C?

I have no idea what this statement actually means, not being a
mathematician.

> It seems almost as if you comp.sci guys are making distinctions about
> variables we math guys don't. Something along the lines of "x" is the
> name of the variable x, whose value is (currently) a fixed constant.

x can be the name of the variable \$x, which can have a current value,
of say, 42. You can then have another variable \$ref which can have a
current value of a reference to \$x. \$ref and \$x are therefore
inextricably linked. Any change you make to the value of \$x would be
reflected in the de-referencing of \$ref.

my \$x = 42;
my \$ref = \\$x;
\$x = 35;
print "Dereferenced ref: \$\$ref\n";
#The above prints 35;

> If this is the right idea, how is this useful in a computational
> context?

Again, I don't know what this means.

Paul Lalli

Paul Lalli, Oct 11, 2005

3. ### A. Sinan UnurGuest

wrote in
news::

> I'm a mathematician who's trying to learn Perl. My knowledge has been
> steadily growing, even though I don't have a computer science
> background. I rely on my familiarity with the mathematical
> abstractions of computation (such as Turing machines and recursive
> functions) to figure out the "essential" semantics of code.
>
> I want to understand references, but I've gone through the relevant
> chapter in "Programming Perl" and have just gone cross-eyed. Can
> someone point (heh) me to a good resource? Preferably one that
> relates the pointer/references paradigm to a mathematical abstraction
> of computation.

I am not sure what you are talking about. I regard the use of
'paradigm' and 'mathematical abstraction of computation' as huge red
flags [1] that indicate that somehow, you are not focusing on the
problem at hand.

I lived with a couple of math Ph.D.'s for a while and occasionally
helped them with their C programs. Neither ever started talking about
Turing machines or paradigms when they did not understand something, and
neither had any problems with the concept of a pointer. When they had
specific issues, we debugged programs by actually looking at the code,
and working with it, rather than philosophizing.

It is important to realize that you cannot become a good programmer just
by thinking in the abstract. You need to practice it.

perldoc perlreftut

especially the section "The Solution".

Do some exercises, ask some practical questions when you don't
understand something.

I am not saying this because I cannot discuss Turing machines with you,
but rather because this is the only way you'll learn to program.

Sinan

[1] I am glad you did not mention "thinking outside of the box".
--
A. Sinan Unur <>
(reverse each component and remove .invalid for email address)

comp.lang.perl.misc guidelines on the WWW:

A. Sinan Unur, Oct 11, 2005
4. ### Guest

Paul Lalli wrote:
> wrote:
> > I'm a mathematician who's trying to learn Perl. My knowledge has been
> > steadily growing, even though I don't have a computer science
> > background. I rely on my familiarity with the mathematical
> > abstractions of computation (such as Turing machines and recursive
> > functions) to figure out the "essential" semantics of code.
> >
> > I want to understand references, but I've gone through the relevant
> > chapter in "Programming Perl" and have just gone cross-eyed. Can
> > someone point (heh) me to a good resource?

>
> perldoc perlreftut
> perldoc perlref
> perldoc perlrefref

Thanks, I'll check them out.

>
>
> > Preferably one that relates
> > the pointer/references paradigm to a mathematical abstraction of
> > computation.

>
> Pointers are not a concept that have much meaning in Perl. Perhaps you
> are thinking of C?
>
> I have no idea what this statement actually means, not being a
> mathematician.
>

Regarding pointers and references, I've seen books/websites/etc (I'm
really tring to avoid using the word "references" here) that say that
references and pointers are just different implementations of the same
underlying idea. I'm looking to understand the underlying idea -- not
just an implementation. For instance, once you understand "procedural
programming," learning how to do procedural programming in Perl and C
is just a matter of figuring out how the languages go about doing it.

> > It seems almost as if you comp.sci guys are making distinctions about
> > variables we math guys don't. Something along the lines of "x" is the
> > name of the variable x, whose value is (currently) a fixed constant.

>
> x can be the name of the variable \$x, which can have a current value,
> of say, 42. You can then have another variable \$ref which can have a
> current value of a reference to \$x. \$ref and \$x are therefore
> inextricably linked. Any change you make to the value of \$x would be
> reflected in the de-referencing of \$ref.
>
> my \$x = 42;
> my \$ref = \\$x;
> \$x = 35;
> print "Dereferenced ref: \$\$ref\n";
> #The above prints 35;

If I understand your example, \$\$ref is a scalar variable whose value is
defined as the value of \$x for all time after \$\$ref is defined. That
is, if \$x changes, \$\$ref changes accordingly. So why introduce \$ref
when

my \$x = 42;
\$x = 35;
print "Dereferenced ref: \$x\n";

outputs the same thing? I realize the example you gave was just to
illustrate what a reference does. I'm just not seeing how a reference
can be useful.

'cid 'ooh

, Oct 11, 2005
5. ### Guest

A. Sinan Unur wrote:
> wrote in
> news::
>
> > I'm a mathematician who's trying to learn Perl. My knowledge has been
> > steadily growing, even though I don't have a computer science
> > background. I rely on my familiarity with the mathematical
> > abstractions of computation (such as Turing machines and recursive
> > functions) to figure out the "essential" semantics of code.
> >
> > I want to understand references, but I've gone through the relevant
> > chapter in "Programming Perl" and have just gone cross-eyed. Can
> > someone point (heh) me to a good resource? Preferably one that
> > relates the pointer/references paradigm to a mathematical abstraction
> > of computation.

>
> I am not sure what you are talking about. I regard the use of
> 'paradigm' and 'mathematical abstraction of computation' as huge red
> flags [1] that indicate that somehow, you are not focusing on the
> problem at hand.
>
> I lived with a couple of math Ph.D.'s for a while and occasionally
> helped them with their C programs. Neither ever started talking about
> Turing machines or paradigms when they did not understand something, and
> neither had any problems with the concept of a pointer. When they had
> specific issues, we debugged programs by actually looking at the code,
> and working with it, rather than philosophizing.

This isn't my intention.{1} I've looked at a bunch of code in the CPAN
and see lots of ->'s. I don't understand their semantics, so I'm
trying to relate what they do with what I already know. Since I don't
have a grounding in comp.sci, reading the Camel book is difficult here
since I don't know a lot of the comp.sci jargon (though I know plenty
of related mathematical jargon).

> It is important to realize that you cannot become a good programmer just
> by thinking in the abstract. You need to practice it.
>
>
> perldoc perlreftut
>
> especially the section "The Solution".
>
> Do some exercises, ask some practical questions when you don't
> understand something.

Thank you, I wasn't aware of this resource. From my limited vantage
point, it looks like references are a big jump in abstraction from what
beginner books deal with. I hadn't found a basic introduction to just
what they do.

'cid 'ooh

>
> I am not saying this because I cannot discuss Turing machines with you,
> but rather because this is the only way you'll learn to program.
>
> Sinan
>
>
> [1] I am glad you did not mention "thinking outside of the box".

{1} It's not my fault marketspeak co-opted "paradigm" and
"abstraction." They're actually useful words when you're talking about
ideas and their implementations. My thinking is strictly in-the-box.

, Oct 11, 2005
6. ### Paul LalliGuest

wrote:
> Regarding pointers and references, I've seen books/websites/etc (I'm
> really tring to avoid using the word "references" here) that say that
> references and pointers are just different implementations of the same
> underlying idea.

I rather disagree with that, but here we're treading on the border of
my knowledge. A pointer is basically an integer memory address. You
can add or subtract values from that value and end up with adjacent (or
nearby) memory location addresses. References, on the other hand refer
to a very specific memory location. You can't get at any other piece
of memory just by manipulating the reference variable.

> > > It seems almost as if you comp.sci guys are making distinctions about
> > > variables we math guys don't. Something along the lines of "x" is the
> > > name of the variable x, whose value is (currently) a fixed constant.

> >

> Paul Lalli wrote:
> > x can be the name of the variable \$x, which can have a current value,
> > of say, 42. You can then have another variable \$ref which can have a
> > current value of a reference to \$x. \$ref and \$x are therefore
> > inextricably linked. Any change you make to the value of \$x would be
> > reflected in the de-referencing of \$ref.
> >
> > my \$x = 42;
> > my \$ref = \\$x;
> > \$x = 35;
> > print "Dereferenced ref: \$\$ref\n";
> > #The above prints 35;

>
> If I understand your example, \$\$ref is a scalar variable

.... no. \$\$ref is not a variable at all. \$ref is a scalar variable,
which holds a reference to \$x. \$\$ref is simply the syntactic means by
which we "dereference" this variable, to get at the the value contained
in the variable that \$ref references.

> whose value is
> defined as the value of \$x for all time after \$\$ref is defined. That
> is, if \$x changes, \$\$ref changes accordingly. So why introduce \$ref
> when
>
> my \$x = 42;
> \$x = 35;
> print "Dereferenced ref: \$x\n";
>
> outputs the same thing? I realize the example you gave was just to
> illustrate what a reference does. I'm just not seeing how a reference
> can be useful.

You're correct - in that simple example, there was no point whatsoever
for \$ref. There are two main areas in which references are useful (or
even vital):

1) multi-dimensional data structures.
Perl has no concept of a "2d array", or "array of arrays". Arrays and
hashes can only hold scalar variables. Therefore, if you want to
simulate a two-dimensional array, you actually create an array which
holds references to more arrays:
my @two_d;
for my \$i (0..5){
my @inner_array = (0..5);
push @two_d, \@inner_array;
}
(The above can be written much more succinctly, but I'm trying to
sacrifice brevity for clarity). This creates a single array - @two_d -
and then loops 6 times. In each iteration of the loop, we create a new
array - @inner_array - and then we store a reference to this new array
in the "outer" array. So now, for example: \$two_d[0], the first
element of @two_d, is a reference to an array of six integers. I can
therefore access, say, the 3rd element of this inner array using:
\$two_d[0][4].

For more on multi-dimensional structures:
perldoc perllol
perldoc perldsc

2) Passing large amounts of data
Say you have a huge hash:
my %big_hash = map ( \$_ => \$_ * 2 } (1..100_000);
(if you're not familiar with the syntax, this simply creates a hash
whose keys are the integers from 1 to 100,000 and whose values are the
even integers from 2 to 200,000).
Now, you want to write a subroutine which accesses and modifies this
data. An initial approach might be:

sub change_something {
my %hash = @_;
\$hash{42} = 'forty-two';
return %hash;
}

%big_hash = change_something(%big_hash);

The problem here is that you've just made three copies of your large
data structure. Three separate instances of all that data had to be
copied, taking up time and space resources in your computer. A better
approach is to store the data once, and have your subroutine just be
given a reference to this data, and modify it:

sub change_something {
my (\$hash_ref) = @_;
\$hash_ref->{42} = 'forty-two';
}

change_something(\%big_hash);

Now we have only ever created one instance of this large data. When we
call change_something, instead of copying all that data, we simply pass
a reference (a single scalar value) to the data. The subroutine gets
that reference, and then directly modifies the data that the reference
references. When the subroutine has completed, the data has been
altered, without making any needless copies.

2b) Passing multiple structures
It directly follows from the above that it is not possible to pass more
than one structure (such as arrays or hashes) into your subroutine and
let your subroutine be able to access the individual elements:

my @foo = (1..10);
my @bar = (11..20);
sums (@foo, @bar);
sub sums {
my @stuff = @_;
#now what? @stuff contains (1..20). No way to know where
#@foo ended and @bar began
}

Instead of passing the actual arrays, we can pass references to those
arrays, so that the sums() subroutine can access the array locations
individually:

my @foo = (1..10);
my @bar = (11..20);
my \$new_array_ref = sums (\@foo, \@bar);
#we can get directly at our new array by dereferencing the above:
my @new_array = @\$new_array_ref;
sub sums {
my (\$arr1, \$arr2) = @_;
my @new_array;
for my \$i (0 .. \$#{\$arr1}){
push @new_array, (\$arr1->[\$i] + \$arr2->[\$i]);
}
return \@new_array;
}

Here, rather than lumping all the elements of both arrays together into
the single @_ array, we were able to obtain the two references, and
then used the two references to access the individual data elements.
When we conclue, we return a reference to the new data, just to avoid
copying the new data structure as well (preferring to allow the calling
code decide if the data needs to be copied).

perldoc perlsub

I hope this rather lengthy post is helpful to you.

Paul Lalli

Paul Lalli, Oct 11, 2005
7. ### Guest

Paul Lalli wrote:
> wrote:
> > Regarding pointers and references, I've seen books/websites/etc (I'm
> > really tring to avoid using the word "references" here) that say that
> > references and pointers are just different implementations of the same
> > underlying idea.

>
> I rather disagree with that, but here we're treading on the border of
> my knowledge. A pointer is basically an integer memory address. You
> can add or subtract values from that value and end up with adjacent (or
> nearby) memory location addresses. References, on the other hand refer
> to a very specific memory location. You can't get at any other piece
> of memory just by manipulating the reference variable.

I have a little bit of knowledge of C, where I was first exposed to the
term "pointer." You're right in that C pointers are just integer
value stored in it. I was inspired to do some experimentation, so I
wrote up the quicky:

my \$x = 42;
my \$ref = \\$x;
my \$ref_2 = \$ref + 2;

print "\\$ref = \$ref\n";
print "\\$ref_2 = \$ref_2\n";
print "\\$\\$ref = \$\$ref\n";
print "\\$\\$ref_2 = \$\$ref_2\n";

whose output is

\$ref = SCALAR(0x10015644)
\$ref_2 = 268523078
\$\$ref = 42
Use of uninitialized value in concatenation (.) or string at
../experiment line 12.
\$\$ref_2 =

It seems that \$ref is just a memory address, though Perl has some built
in functionality to keep me from jumping around arbitrarily. Indeed,
the code won't compile at all if strict is used. I wonder, however, if
there is a way to write to arbitrary memory addresses. That way I
could define \$\$ref_2 without declaring that \$ref_2 is a reference to
another variable. This is all that is missing from their equivalence.

All in all, it seems to me that C pointers are slightly more general
than Perl references -- or equivalently, that Perl references are more
structured.

>
> I hope this rather lengthy post is helpful to you.
>

Yes, it is definitely helpful. Thank you for taking the time to write
it. Now that I understand what they're for, learning the syntax will
be a peice of motivated cake.

'cid 'ooh

, Oct 11, 2005
8. ### BabacioGuest

writes:

> I want to understand references, but I've gone through the relevant
> chapter in "Programming Perl" and have just gone cross-eyed. Can
> someone point (heh) me to a good resource? Preferably one that relates
> the pointer/references paradigm to a mathematical abstraction of
> computation.

Being a mathematician (well, at least for a few monthes from now,
after that I may be an unemployed ex-mathematician or a math teacher
or whatever), I have sometimes the same kind of preoccupations.

When you'll arive to closures and static variables, it will be even
more funny to try that... in fact, the underlying mathematics of
modern computing languages seems to involves relatively new
concepts. Type theory may be usefull, but it's not enough. Object
oriented programming has something to do with category theory, well,
or at least I have this feeling.

References seem indeed very exotic from a mathematical point of
view... a first idea: one introduces sometimes some redondant notation
in a math text ; references allow to do that, in some sense ; but
that's not exactly true, because you have the original variable, and
its reference, and you need to derefence it before using it as you
would use the original. They are definitvely not of the same
nature. This mathematical habit seems more related to the operator :=
defined by Perl6::Binding.

Moreover, a reference to an anonymous object is something very useful,
but definitively different from the above idea.

In Perl, a reference to a scalar is scalar, that doesn't ease the
problem. In a strongerly typed language, a reference would have a type
like « reference to an integer », which is something you can't write
(as far as I know) in mathematical type theory ! it's linked to the
way a computer works, having a pointer in C is something very natural
when you think of it in a concrete point of view -- and references
seem to me to be very near to pointers, with a greater level of
abstraction.

My conclusion is that there is no widely spread math concept
corresponding to references.

They tell that Lafont's linear logic should ease the understanding of
variable managing, and so one. I have no idea of that, if you have
time to learn linear logic, that may interest you.

--
Bé erre hue ixe eu elle, Bruxelles.

Babacio, Oct 11, 2005
9. ### BabacioGuest

"Paul Lalli"

> I rather disagree with that, but here we're treading on the border of
> my knowledge. A pointer is basically an integer memory address. You
> can add or subtract values from that value and end up with adjacent (or
> nearby) memory location addresses. References, on the other hand refer
> to a very specific memory location. You can't get at any other piece
> of memory just by manipulating the reference variable.

....that's what I called « a greater abstraction level ». I think you
cannot have pointers in Perl because of the Garbage Collector -- I may
be saying total bullshit here, feel free to curse.

But I think references are the descendants of pointers. They sure have
a better look from the mathematical point of view, that pointers do,
they seem abstract enough to be integrated in an extension of type
theory.

--
Bé erre hue ixe eu elle, Bruxelles.

Babacio, Oct 11, 2005
10. ### BabacioGuest

poopdeville.

> my \$x = 42;
> my \$ref = \\$x;
> my \$ref_2 = \$ref + 2;
> (...)

> It seems that \$ref is just a memory address, though Perl has some built
> in functionality to keep me from jumping around arbitrarily.

Ay, it's a kind of blaspheme!

You're touching to the way references are *implemented* in perl, not
to what they *are* in Perl. If you speak spanish, that's the
difference between 'estar' and 'ser'!

And here is a quote from the faq, to help understant why I wrote perl
vs Perl above:

Larry now uses "Perl" to signify the language proper and "perl" the
implementation of it, i.e. the current interpreter.

Yes, references are implemented like pointers in perl, but they are
not pointers in Perl.

> All in all, it seems to me that C pointers are slightly more general
> than Perl references -- or equivalently, that Perl references are more
> structured.

Yes, indeed.

--
Bé erre hue ixe eu elle, Bruxelles.

Babacio, Oct 11, 2005
11. ### Paul LalliGuest

wrote:
> my \$x = 42;
> my \$ref = \\$x;
> my \$ref_2 = \$ref + 2;
>
> print "\\$ref = \$ref\n";
> print "\\$ref_2 = \$ref_2\n";
> print "\\$\\$ref = \$\$ref\n";
> print "\\$\\$ref_2 = \$\$ref_2\n";
>
> whose output is
>
> \$ref = SCALAR(0x10015644)
> \$ref_2 = 268523078
> \$\$ref = 42
> Use of uninitialized value in concatenation (.) or string at
> ./experiment line 12.
> \$\$ref_2 =
>
> It seems that \$ref is just a memory address, though Perl has some built
> in functionality to keep me from jumping around arbitrarily.

Ehhh, it's not that simple. As you can see when you printed the value
of \$ref, \$ref is not holding a simple integer. More correctly, Perl
contains some "magic" that will treat \$ref as the integer representing
the memory location if you happen to use \$ref as a number (ie, by
adding to it, as you did above).

> Indeed, the code won't compile at all if strict is used.

Correct. Specifically, because \$ref_2 is not a reference at all. It
actually *is* a simple integer (unlike \$ref, which merely *acted* like
an integer for the benefit of the + operation). Without strict in
place, Perl was attempting to use the value of \$ref_2 as the *name* of
a variable to print (ie, it was looking for the variable \$268523078
(which obviously did not exist), *not* for the contents of the memory
location 268523078). This is known as "symbollic references", which
are a whole 'nother topic entirely, and are generally considered
extremely poor programming practice. This is the reason that 'use
strict;' prevents their use.

> I wonder, however, if
> there is a way to write to arbitrary memory addresses. That way I
> could define \$\$ref_2 without declaring that \$ref_2 is a reference to
> another variable.

I am at a loss as to why you would want to do such a thing. Why would
you ever *want* to write to an arbitrary memory location? Such things
are necessary in C because, for example, strings are implemented as
contiguous blocks of memory that each contain a single character. No
such thing applies to Perl.

> This is all that is missing from their equivalence.

See my description above for why I disagree with this assessment.

> All in all, it seems to me that C pointers are slightly more general
> than Perl references -- or equivalently, that Perl references are more
> structured.

I still don't *quite* agree with that, but I will freely admit that C
pointers and Perl references have more than a little in common.

> <snip lengthy and helpful exposition>
> >
> > I hope this rather lengthy post is helpful to you.
> >

>
> Yes, it is definitely helpful. Thank you for taking the time to write
> it. Now that I understand what they're for, learning the syntax will
> be a peice of motivated cake.

Paul Lalli

Paul Lalli, Oct 11, 2005
12. ### Guest

"Paul Lalli" <> wrote:
> wrote:
> > my \$x = 42;
> > my \$ref = \\$x;
> > my \$ref_2 = \$ref + 2;
> >
> > print "\\$ref = \$ref\n";
> > print "\\$ref_2 = \$ref_2\n";
> > print "\\$\\$ref = \$\$ref\n";
> > print "\\$\\$ref_2 = \$\$ref_2\n";
> >

....
> > Indeed, the code won't compile at all if strict is used.

>
> Correct.

Not correct. The code compiles fine under strict. It does throw
a run time error when you try to dereference something which is not
a reference, though.

Xho

--
Usenet Newsgroup Service \$9.95/Month 30GB

, Oct 11, 2005
13. ### Paul LalliGuest

wrote:
> "Paul Lalli" <> wrote:
> > wrote:
> > > my \$x = 42;
> > > my \$ref = \\$x;
> > > my \$ref_2 = \$ref + 2;
> > >
> > > print "\\$ref = \$ref\n";
> > > print "\\$ref_2 = \$ref_2\n";
> > > print "\\$\\$ref = \$\$ref\n";
> > > print "\\$\\$ref_2 = \$\$ref_2\n";
> > >

> ...
> > > Indeed, the code won't compile at all if strict is used.

> >
> > Correct.

>
> Not correct. The code compiles fine under strict. It does throw
> a run time error when you try to dereference something which is not
> a reference, though.

Ah. Quite true. Run-time error, not compile-time. Thanks for the
correction, Xho.

Paul Lalli

Paul Lalli, Oct 11, 2005
14. ### Sherm PendleyGuest

writes:

> trying to relate what they do with what I already know. Since I don't
> have a grounding in comp.sci, reading the Camel book is difficult

I think it's worth pointing out that the Camel is not meant to be an intro
to programming - it's a reference (ouch) manual for those who already know

If you're new to programming, you'd be far better off with the Llama -
"Learning Perl".

As a mathemetician, you'd also do well to study the classics in comp sci -
Knuth's "The Art of Computer Programming", which are very heavy on theory
and formal proofs.

> Thank you, I wasn't aware of this resource. From my limited vantage
> point, it looks like references are a big jump in abstraction from what
> beginner books deal with. I hadn't found a basic introduction to just
> what they do.

Have a look at the second "Learning" book - "Learning Perl Objects,
References, and Modules".

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Sherm Pendley, Oct 11, 2005
15. ### Tassilo v. ParsevalGuest

Also sprach :

> I have a little bit of knowledge of C, where I was first exposed to the
> term "pointer." You're right in that C pointers are just integer
> memory addresses. Given an integer address, you can figure out the
> value stored in it. I was inspired to do some experimentation, so I
> wrote up the quicky:
>
> my \$x = 42;
> my \$ref = \\$x;
> my \$ref_2 = \$ref + 2;
>
> print "\\$ref = \$ref\n";
> print "\\$ref_2 = \$ref_2\n";
> print "\\$\\$ref = \$\$ref\n";
> print "\\$\\$ref_2 = \$\$ref_2\n";
>
> whose output is
>
> \$ref = SCALAR(0x10015644)
> \$ref_2 = 268523078
> \$\$ref = 42
> Use of uninitialized value in concatenation (.) or string at
> ./experiment line 12.
> \$\$ref_2 =
>
> It seems that \$ref is just a memory address, though Perl has some built
> in functionality to keep me from jumping around arbitrarily. Indeed,
> the code won't compile at all if strict is used. I wonder, however, if
> there is a way to write to arbitrary memory addresses. That way I
> could define \$\$ref_2 without declaring that \$ref_2 is a reference to
> another variable. This is all that is missing from their equivalence.
>
> All in all, it seems to me that C pointers are slightly more general
> than Perl references -- or equivalently, that Perl references are more
> structured.

This is one difference between those two. However, it should be noted
that C and C++ have a special approach to pointers that is not present
in any other language with the pointer concept I know of. When you wrote

my \$ref_2 = \$ref + 2;

you were thinking of pointer arithmetic, but many languages which have
pointers (all languages in the Pascal family for example) explicitely
forbid it.

In C a pointer contains a memory-address. But that is not all. Attached
to a pointer is also the information on how big the datum to be found in
that memory-address is. This size is used when you add or substruct
numbers from a pointer:

int *p = function();

/* let's assume that p holds the address 10000 */

p++;

/* p is now 10000 + sizeof(int), 10004 on 32bit machines */

Expanding a bit on this:

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char **argv) {

int *p = (int*) malloc (sizeof(int));
char *c = (char*)p;

if ((unsigned)p == (unsigned)c)
printf("p and c have same address: %p == %p\n", p, c);
else
printf("p and c have different addresses: %p != %p\n", p, c);

p++; c++;

if ((unsigned)p == (unsigned)c)
printf("p and c have same address: %p == %p\n", p, c);
else
printf("p and c have different addresses: %p != %p\n", p, c);

return 0;

}

That yields:

p and c have same address: 0x80497b0 == 0x80497b0
p and c have different addresses: 0x80497b4 != 0x80497b1

As you can see, the int-pointer is advanced by four bytes, the
char-pointer only by one, thereby having them point to different memory
positions.

Perl's references on the other hand only contain an address, but they
don't have a size of the referenced datum attached to them. This is the
reason why you can't use only references to implement an array of values
as you can do in C and C++. For that you'd need the size information
because otherwise you don't know how many byte positions to seek forward
when incrementing the reference.

What should be noted is that pointers or references may have different,
possibly more intuitive names, in other languages. Ada calls them
'access types'. The idea is that such a pointer or reference thingy is
another way to access a specific value:

my \$val = 42;
my \$ref = \\$val;

print \$val; # one way to access it
print \$\$ref; # another way

You raised the question why it is necessary to have that second way of
accessing at all and why not simply use the variable that contains the
value. In C and C++ at least pointers are inevitable if you want to
acquire memory from the operating system in a dynamic manner. If you
want memory big enough to store 10 integers, how would you handle that
memory block other than using a variable that contains the address of
the first byte of that block? You can no longer use a simple integer
variable because you have space for ten integers. And so you get a
pointer. Incidentally, in C a pointer is an array:

int *ary = (int*)malloc(10 * sizeof(int));
for (i = 0; i < 10; i++)
ary = i;

and vice versa:

/* same as above, but memory is not allocated
* at runtime on the heap: Instead memory pointed
* to be ary is on the stack. */
int ary[10];
for (i = 0; i < 10; i++)
*(ary + i) = i;

>>
>> I hope this rather lengthy post is helpful to you.
>>

>
> Yes, it is definitely helpful. Thank you for taking the time to write
> it. Now that I understand what they're for, learning the syntax will
> be a peice of motivated cake.

There are other situations where pointer/references are needed. You need
them for recursive data-structures, such as a linked list or so:

struct list {
int val; /* sizeof(int) bytes */
struct list next; /* ??? bytes */
};

This wont work because the compiler needs to know in advance the size of
each member of a structure to calculate the overall size. But 'struct
list' inside itself is incomplete. So instead:

struct list {
int val; /* sizeof(int) bytes */
struct list *next; /* sizeof(ptr) bytes */
};

Another domain for pointers and references is the mechanism
unimaginatively called 'call-by-reference'. That is, a function that
receives an argument which it may change in place by following the
reference:

use List::MoreUtils qw/none/;

sub push_uniq {
my (\$ref, \$val) = @_;
push @\$ref, \$val if none { \$_ eq \$val } @\$ref;
}

my @list = (1, 2, 3);
push_uniq \@list, \$_ for 1 .. 5;

# @list now (1, 2, 3, 4, 5)

Tassilo
--
use bigint;
\$n=71423350343770280161397026330337371139054411854220053437565440;
\$m=-8,;;\$_=\$n&(0xff)<<\$m,,\$_>>=\$m,,print+chr,,while((\$m+=8)<=200);

Tassilo v. Parseval, Oct 12, 2005

Paul Lalli wrote:
....
> You're correct - in that simple example, there was no point whatsoever
> for \$ref. There are two main areas in which references are useful (or
> even vital):
>
> 1) multi-dimensional data structures.

....
> 2) Passing large amounts of data

....
> 2b) Passing multiple structures

....