in reply to Re: referencing slices - love that DWIM
in thread referencing slices - love that DWIM

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
  • Comment on Re^2: referencing slices - love that DWIM

Replies are listed 'Best First'.
Re^3: referencing slices - love that DWIM
by almut (Canon) on May 17, 2008 at 12:42 UTC
    ... 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...

[reply]
      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
[reply]
[d/l]
[select]

        A list is an ephermeral thing; a transient set of values on the call stack. There's no way to take a reference to it since it has no permanent home to which to refer. An array on the other hand has a permanent location in memory to which a pointer can be obtained.

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.

[reply]
        ... then wouldn't [\(@foo)] have to return a reference to that list ?

        Not sure what it would have to... :)  but as it is, it returns a reference to an anonymous array which has been initialised with references to the list's individual elements/values. Something quite different.

[reply]
[d/l]
        To me, it is blatantly obvious that DWIMness dictates that \(@foo) ought to return the same as [@foo]
        I've never liked \(@foo) and thought it should be no different from \@foo (a reference to the array @foo).
        My reasoning (undoubtedly flawed) is along the lines that the square brackets ([]) return a reference to whatever is within those brackets ...
        Flawed, yes. [] creates a new array, initialized from the list given, and returns a reference to it. This differs from "return[ing] a reference to whatever is within" in that it is a shallow copy, so \@foo is affected by later changes to @foo's elements, while [@foo] is not (unless those elements are references to other things which are changed.)
        --
        Online Fortune Cookie Search
[reply]

In Section Meditations