I'll agree the wording was potentially misleading. I didn't read it to mean what it could have been read to mean, as I didn't make any assumptions about "always" or assume any implied meaning. It would be easy to read more than face value into that text. I didn't, BTW, s/said/implied and I really meant exactly "said" in that case. I know I'm not always so precise, but this time I was. That's one of the problems with natural language.

A slice does make that same return decision based on context, but that's at the implementation level. At the language level the description can usually be abstracted away, because there is no simple way to redefine the return behavior of the slice from Perl. What they return in scalar context is effectively fixed unless you're pulling dirty tricks on your code's next maintainer.

Subroutines can easily be changed to care or not care about the calling context and to do different things if they care (or even based on the caller or other things more esoteric than the context) at the Perl level. Named built-in procedures look and act like more like subs than variable accesses do. Therefore, it's often easier to explain them in terms of Perl-level behavior of subs than C-level behavior of RHS and LHS in the interpreter.

Speaking of contexts, human conversation has context, too. A big part of that context is the abstraction level of the concepts involved. For effective communication, one usually doesn't intermingle abstraction levels without delineating them. If you choose to abstract slice accesses differently than FunkyMonk, then that's fair. I think you're intermingling the Perl language level with how perl does Perl under the hood in the middle of a language-level a bit differently than some other people in the thread are. Once they come to understand what you're actually discussing or you agree to write about what they are actually discussing, then it'll be easier for everyone to be clear and save everyone some headaches.

I'm not going to arbitrate which level is more suitable or which abstraction at the language level for slices (the one that more closely matches the implementation or the one that's IMO frankly clearer to people coming from a C-like language POV) is a better way to present the idea. I think it may be fruitful for the participants of the thread to recognize that the whole thread is a muddled mess of conflicting descriptions from different levels which eventually could be understood the same way. Different readers will understand one better than the other, but it's easier once both are put forward if the differences between them are made apparent.

In reply to Re^9: Scalar context of slice (vs grep) by mr_mischief
in thread Scalar context of slice by thenaz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.