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
    #1
    1. Advertising

  2. Paul Lalli Guest

    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
    #2
    1. Advertising

  3. 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.

    You might not like this response, but please read:

    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:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
     
    A. Sinan Unur, Oct 11, 2005
    #3
  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.

    Thank you for your input.

    'cid 'ooh
     
    , Oct 11, 2005
    #4
  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.
    >
    > You might not like this response, but please read:
    >
    > 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
    #5
  6. Paul Lalli Guest

    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).

    For more info on subroutine parameters:
    perldoc perlsub

    I hope this rather lengthy post is helpful to you.

    Paul Lalli
     
    Paul Lalli, Oct 11, 2005
    #6
  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
    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.

    <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. :)

    'cid 'ooh
     
    , Oct 11, 2005
    #7
  8. Babacio Guest

    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
    #8
  9. Babacio Guest

    "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
    #9
  10. Babacio Guest

    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
    #10
  11. Paul Lalli Guest

    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. :)


    Glad I could help.

    Paul Lalli
     
    Paul Lalli, Oct 11, 2005
    #11
  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

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Oct 11, 2005
    #12
  13. Paul Lalli Guest

    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
    #13
  14. 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
    how to program, and want to learn more about the Perl language.

    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
    #14
  15. 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;

    ><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. :)


    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
    #15
  16. Brad Guest

    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

    ....

    To which I might add

    3) Perl's approach to OOP in which objects are handled via references.

    --Brad
     
    Brad, Oct 15, 2005
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. TJS
    Replies:
    1
    Views:
    1,704
    Kevin Spencer
    Mar 2, 2005
  2. Jim in Arizona
    Replies:
    4
    Views:
    7,958
    Jim in Arizona
    Aug 24, 2005
  3. Vijay
    Replies:
    4
    Views:
    1,315
    Vijay
    Apr 13, 2005
  4. david wolf
    Replies:
    1
    Views:
    589
    Oliver Wong
    Apr 21, 2006
  5. H5N1
    Replies:
    0
    Views:
    2,723
Loading...

Share This Page