in reply to Re^17: If you believe in Lists in Scalar Context, Clap your Hands
in thread If you believe in Lists in Scalar Context, Clap your Hands

The problem is not about what happens, which is eminently described by your rules.

The problem is how to discuss what happens and why, without complex ascii-art diagrams, or multiply subscripted essays, for the two common results of symbolic (source code) expressions that appear (conceptually) to produce multiple values, when those constructs occur (directly or indirectly) in a scalar context. Namely:

  1. They result in a scalar that is the number of those multiple values that would have been produce had that same construct appeared in a list context. 
    @a = 'a'..'d';;

print @a;;
a b c d

print scalar @a;;
4

    [download]
  2. They result in a scalar that is 'last' value of the multiple scalars that would have been produced had the same expression appeared in a list context. 
    print('a'..'d');;
a b c d

print scalar ('a','b','c','d');;
d

    [download]

In the context of the original thread, the question was asked: Why does a slice @a[0..$#a] produce a different result in a scalar context to the array, when they both produce identical results in a list context. (Or meaning to that effect.)

And the reply (with licence), that started this discussion, was: Because a slice acts like a list in a scalar context.

The problem that arises is that people, (those in the know), will insist on taking that use of the word 'list' to mean some ethereal, maybe-exists or maybe-doesn't, internal state; rather than the more general, more useful, concrete concept of what has (in at least one post) been alternatively named a 'list constant'.

So, in order to be able to discuss and relate to discussion, and to be able to categorise the effects of the many constructs in a scalar context, the following two phrases might be used to relate any given expression to the well known and broadly understood situations in 1 & 2 above:

  1. The result of expression X in a scalar context, will be a count of the items in the list produced where that same expression appears in a list context. Similar in effect, to when an array expression appears in a scalar context.
  2. The result of expression X in a scalar context, will be the last item from the list that would have been produced where that same expression appears in a list context. Similar in effect, to when a list (constant) appears in a scalar context.

And those two wordy (and I hope inarguably accurate:), phrases should be replacable by:

  1. In a scalar context, expression X acts similarly to an array expression.
  2. In a scalar context, expression X acts similarly to a list (constant).

In turn, if people would accept that in the context[sic] of posts like the one that started this saga, that the term 'list' is most likely to mean the concrete variety, rather than the nebulous, ethereal source divers-only meaning, then the phrase "It acts like a list in a scalar context", is a simple, convenient and conceptually accurate way of describing what happens when (for example), an array slice expression appears in a scalar context.

For me, the crux of this whole saga is that attempt by certain somebodies to infer a meaning from the use of the term 'list' that simple doesn't appear on the horizons of most SoPWs; nor even the greater majority of Perlers. And then jump on people because of that (wrong) inference.

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^19: If you believe in Lists in Scalar Context, Clap your Hands
by ikegami (Patriarch) on Oct 26, 2008 at 04:11 UTC

    So is "it returns the last element". Pick whichever one you want.

    By the way, I didn't jump on anyone for saying "list in scalar context" either in this discussion or in the last discussion.

[reply]
      Node is updated for clarity and to remove irrelevant detail that distracted from the point. October 28th, 2008

      I'm sorry if it read as if I thought you did jump on anyone. That was not my intention. I meant "you" in a plural number as those who have been holding up the explanation you offer as a group. I was not clear enough at that, and I apologize.

      My issue in this debate isn't that people have a preferred abstraction, that they claim the issue is clearer without any abstraction at all, nor that they will state the advantages of one and the disadvantages of the other. My primary issue is that people seem to be overlooking the background necessary to understand the alternatives vs. the stated drawbacks of the abstraction at hand. My secondary issue is that those of us defending the use of what may be an unorthodox abstraction are being wrongly ascribed some firmly held wrong belief about how perl actually works.

      I've been called dismissive in these two threads. That may be fair, but I'm not the only one here capable of that. It can seem that some of those who know how perl interprets Perl intimately are dismissive of all the education, training, and experience it took for them to get to that point. They expect that as a base level for useful discussion of syntax and semantics, which I think may show a disconnect between them and the people who depend upon this "rules and exceptions" abstraction for how Perl (with no mention of perl itself) deals with "lists" (in the plain English meaning with no idea of "list value" vs. "list context" vs. "syntactic sugar list of scalars").

      I think some folks have been dismissive of abstractions that are too far from the interpreter (without, IMO, being too far from describing what can be said to be happening within Perl, the language). I also think some have made up their minds a bit too early about those of us who are suggesting a strictly imprecise abstraction can still be accurate enough within a certain mental model and have been discounting our statements because they don't immediately see the merit.

      I think that some people are not willing to give up their mental model at a particular moment, even if they are willing to do so in the future. I think dismissing the idea that people really do prefer to build on a partly false model can be harmful. I think insisting to them that they learn from the question they are asking back down through a different set of basic ideas than what they have already learned can be counterproductive.

      I think some monks have, probably unintentionally, been somewhat narrow-minded in thinking that because a model more accurately describes what actually happens that it is necessarily more useful to the person using the model. I think some of them could have been a bit more polite in stating their case, too. I'm sorry if I seemed to group you into those.

      I do not think anyone, even Larry or Damian, knows how every single Perl programmer would best go through the learning process about the language. Sure, they can tell you what really happens in the code. They can tell you in what terms they think about it. They can tell someone what abstraction seems to be helpful to most people from their experience, or which matches their own ideas the closest. Yet if they would say that someone with a certain level of understanding will always be helped or always be harmed in gaining their next bit of understanding about using the language by one particular idea and point of view, then they would probably be wrong. Certain abstractions may help more people than others, but how does one know which helps a certain individual more without presenting more than one?

[reply]

In Section Meditations