What Will This Print?

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Nov 10, 2009.

  1. Found this in a fla^H^H^Hdiscussion about Perl. The following command

    perl -wle 'sub fun { print map $_++, 1..3; } fun(); fun();'

    prints two lines. The first one is

    123

    What's the second line?
     
    Lawrence D'Oliveiro, Nov 10, 2009
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:hdcson$6v6$...
    > Found this in a fla^H^H^Hdiscussion about Perl. The following command
    >
    > perl -wle 'sub fun { print map $_++, 1..3; } fun(); fun();'
    >
    > prints two lines. The first one is
    >
    > 123
    >
    > What's the second line?


    234
     
    Nik Coughlin, Nov 11, 2009
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "Nik Coughlin" <> wrote in message
    news:hdd4rp$d1p$-september.org...
    > "Lawrence D'Oliveiro" <_zealand> wrote in message
    > news:hdcson$6v6$...
    >> Found this in a fla^H^H^Hdiscussion about Perl. The following command
    >>
    >> perl -wle 'sub fun { print map $_++, 1..3; } fun(); fun();'
    >>
    >> prints two lines. The first one is
    >>
    >> 123
    >>
    >> What's the second line?

    >
    > 234


    And the reason is that the implicit $_ is global and you really shouldn't
    modify it
     
    Nik Coughlin, Nov 11, 2009
    #3
  4. In message <hdd53n$er7$-september.org>, Nik Coughlin wrote:

    > "Nik Coughlin" <> wrote in message
    > news:hdd4rp$d1p$-september.org...
    >
    >> "Lawrence D'Oliveiro" <_zealand> wrote in message
    >> news:hdcson$6v6$...

    >
    >>> Found this in a fla^H^H^Hdiscussion about Perl. The following command
    >>>
    >>> perl -wle 'sub fun { print map $_++, 1..3; } fun(); fun();'
    >>>
    >>> prints two lines. The first one is
    >>>
    >>> 123
    >>>
    >>> What's the second line?

    >>
    >> 234

    >
    > And the reason is that the implicit $_ is global and you really shouldn't
    > modify it


    Right answer, wrong reason.
     
    Lawrence D'Oliveiro, Nov 11, 2009
    #4
  5. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:hddcvs$gbv$...
    > In message <hdd53n$er7$-september.org>, Nik Coughlin wrote:
    >
    >> "Nik Coughlin" <> wrote in message
    >> news:hdd4rp$d1p$-september.org...
    >>
    >>> "Lawrence D'Oliveiro" <_zealand> wrote in
    >>> message
    >>> news:hdcson$6v6$...

    >>
    >>>> Found this in a fla^H^H^Hdiscussion about Perl. The following command
    >>>>
    >>>> perl -wle 'sub fun { print map $_++, 1..3; } fun(); fun();'
    >>>>
    >>>> prints two lines. The first one is
    >>>>
    >>>> 123
    >>>>
    >>>> What's the second line?
    >>>
    >>> 234

    >>
    >> And the reason is that the implicit $_ is global and you really shouldn't
    >> modify it

    >
    > Right answer, wrong reason.


    What's happening? I know that if you don't try to post inc the implicit
    variable $_ thingy (forget what it's called but know what it does) and just
    let it do its thing then it works as expected:

    sub fun { print map $_, 1..3; } fun(); fun();
     
    Nik Coughlin, Nov 11, 2009
    #5
  6. In message <hddfbm$hn8$-september.org>, Nik Coughlin wrote:

    > "Lawrence D'Oliveiro" <_zealand> wrote in message
    > news:hddcvs$gbv$...
    >
    >> In message <hdd53n$er7$-september.org>, Nik Coughlin wrote:
    >>
    >>> And the reason is that the implicit $_ is global and you really
    >>> shouldn't modify it

    >>
    >> Right answer, wrong reason.

    >
    > What's happening?


    It's that the "$_" name becomes an _alias_ for the list element within the
    invocation of the map function. Thus, any change to its value causes a
    corresponding change to that list element.

    This is documented in the perlfunc(5) man page.

    This phenomenon bears an eerie resemblance to a (mis)feature of early
    FORTRAN compilers, where something like

    SUBROUTINE MUNGE(I)
    I = I + 1
    END
    ...
    CALL MUNGE(1)

    would cause all references to the literal number “1†in the program to
    mysteriously have the value “2†instead.
     
    Lawrence D'Oliveiro, Nov 11, 2009
    #6
  7. Lawrence D'Oliveiro

    Nik Coughlin Guest

    "Lawrence D'Oliveiro" <_zealand> wrote in message
    news:hddj6l$jqn$...
    > In message <hddfbm$hn8$-september.org>, Nik Coughlin wrote:
    >
    >> "Lawrence D'Oliveiro" <_zealand> wrote in message
    >> news:hddcvs$gbv$...
    >>
    >>> In message <hdd53n$er7$-september.org>, Nik Coughlin
    >>> wrote:
    >>>
    >>>> And the reason is that the implicit $_ is global and you really
    >>>> shouldn't modify it
    >>>
    >>> Right answer, wrong reason.

    >>
    >> What's happening?

    >
    > It's that the "$_" name becomes an _alias_ for the list element within the
    > invocation of the map function. Thus, any change to its value causes a
    > corresponding change to that list element.
    >
    > This is documented in the perlfunc(5) man page.
    >
    > This phenomenon bears an eerie resemblance to a (mis)feature of early
    > FORTRAN compilers, where something like
    >
    > SUBROUTINE MUNGE(I)
    > I = I + 1
    > END
    > ...
    > CALL MUNGE(1)
    >
    > would cause all references to the literal number “1†in the program to
    > mysteriously have the value “2†instead.


    Then there is the issue of when a language standard doesn't define what
    should happen in ambiguous situations.

    Consider the following C++ :

    int n = 3;
    int something = Sum( n, ++n );

    The C++ standard doesn't define the order in which function params are
    evaluated, so in come compilers this is the same as Sum( 3, 4 ) and in
    others Sum( 4, 4 )

    There are even differences with the same compiler across different
    platforms.

    Compare for example gcc on an x86 platform vs gcc on an ARM platform vs GCC
    on PPC etc to see this in action.

    Difference in evaluation between x86 and PPC:

    int n = 3;
    printf( "%d %d %d", n++, n++, n++ );

    x86 = 5 4 3
    PPC = 3 4 5
     
    Nik Coughlin, Nov 12, 2009
    #7
  8. In message <hdg5pv$h4m$-september.org>, Nik Coughlin wrote:

    > The C++ standard doesn't define the order in which function params are
    > evaluated ...


    Lots of languages don't.
     
    Lawrence D'Oliveiro, Nov 12, 2009
    #8
    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. =?Utf-8?B?cGVjaw==?=

    Can't print to print server

    =?Utf-8?B?cGVjaw==?=, Feb 2, 2005, in forum: Wireless Networking
    Replies:
    2
    Views:
    683
    =?Utf-8?B?cGVjaw==?=
    Feb 3, 2005
  2. =?Utf-8?B?enljZ3M=?=
    Replies:
    1
    Views:
    554
    Daz N
    Jan 4, 2005
  3. epl

    Print sharing -- why can't I print?

    epl, Sep 14, 2003, in forum: Computer Support
    Replies:
    1
    Views:
    437
  4. vddiee
    Replies:
    2
    Views:
    2,859
    vddiee
    Jul 16, 2004
  5. Bun Mui
    Replies:
    3
    Views:
    840
    Phantom
    Sep 13, 2004
Loading...

Share This Page