in reply to referencing slices - love that DWIM

See subsection 2 of perlref:Making references where it says:

As a special case, \(@foo) returns a list of references to the contents of @foo, not a reference to @foo itself

Just for fun try:

print "$_" for \( %{{a =>1}}, @{[1..3]}, "fred" );; HASH(0x2251b8) ARRAY(0x194a9f4) SCALAR(0x194aaa8)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: referencing slices - love that DWIM
by GrandFather (Saint) on May 17, 2008 at 11:59 UTC

    With the implication (extrapolated from the perlref quote) that \ notices that it is operating on a list and generates a list of references rather than a reference to list. I had a feeling that I'd seen something more explicit than that, although the quote from the docs does shed a some light on why it does what it does.


    Perl is environmentally friendly - it saves trees
      ... rather than a reference to list

      I think there is no such thing as a reference to a list, because a list - in contrast to an array - is not internally represented in a way that it could be referenced in its entirety...

        I think there is no such thing as a reference to a list

        1) BrowserUK quoted the documentation that  \(@foo) returns a list of references. Assuming that \(@foo) does, in fact, return a list (as stated by that documentation), then wouldn't [\(@foo)] have to return a reference to that list ?

        2) I find it amazing that the current implementation of \(@foo) DWIMs for so many people. To me, it is blatantly obvious that DWIMness dictates that \(@foo) ought to return the same as [@foo]. (I know one other who shares the same view - but I have no doubt that we are in a minority.)

        3) I should acknowledge that I don't really understand "lists" - and, having read numerous explanations, have grown to accept the fact that I probably never will.

        Cheers,
        Rob