in reply to Re^6: chopping a string into slices - is there a more elegant way to do it?
in thread chopping a string into slices - is there a more elegant way to do it?

To correct myself, there are very special situations where parens affect the result. eof vs eof() and (...)x... vs ...x..., for example. And of course ($x)=... vs $x=....

But while parens sometimes do more than control precedence, I can't think of anywhere where non-empty parens create a list context.

The parens in ($a)=@_ don't affect context. They cause a list assignment operator (aassign) to be used instead of a scalar assignment operator (sassign).

That said, it's very convenient to think that some parens create a list, even when it isn't technically true. But the code being discussed definitely does not contain parens which could be thought of as "list forming".

Replies are listed 'Best First'.
Re^8: chopping a string into slices - is there a more elegant way to do it?
by gone2015 (Deacon) on Dec 01, 2008 at 22:44 UTC

    I've just been tripped up by:

      my @foo = (2, 3,  4  x 17, 3, 2, 0, 0)

    being quite different from:

      my @foo = (2, 3, (4) x 17, 3, 2, 0, 0)

    which looks as if the '()' confer some quality of list-ness. The documentation says:

    .... In scalar context or if the left operand is not enclosed in parentheses, it returns a string consisting of the left operand repeated the number of times specified by the right operand. In list context, if the left operand is enclosed in parentheses or is a list formed by qw/STRING/, it repeats the list.

    so the brackets are part of the syntax... I confess that I was (for reasons unknown) expecting 'x' to do listy things in List Context and scalary things otherwise. (Many things take lists of arguments, so I guess it would be inconvenient for (e.g.) '-' x 24 to yield a list in List Context.)

    Similarly, of course,  foreach VAR(LIST) BLOCK reenforces the feeling that '()' have something to do with the making of lists.

[reply]
[d/l]
[select]

      I confess that I was (for reasons unknown) expecting 'x' to do listy things in List Context and scalary things otherwise

      I recall the developers of Perl a bit ashamed of that one. I don't know if it was done that way for backwards compatibility or if it was simply a case of the consequences not being anticipated. It really does break the mold.

      Similarly, of course, foreach VAR (LIST) BLOCK reenforces the feeling that '()' have something to do with the making of lists.

      Really? 

      for (foo()) { bar() }    # List
while (foo()) { bar() }  # Scalar
if (foo()) { bar() }     # Scalar
print(foo())             # List
length(foo())            # Scalar

      [download]

      I even use for as a topicalizer regularly. 

      for ($var) {             # Scalar
   s/^/[/;
   s/$/]/;
}

      [download]

      The purpose of parens in flow control statements in Perl5 is purely decorative. However, their roots are in C, where their purpose is for precedence.

[reply]
[d/l]
[select]
Re^8: chopping a string into slices - is there a more elegant way to do it?
by LanX (Saint) on Nov 30, 2008 at 17:28 UTC
    > The parens in ($a)=@_ don't affect context. They cause a list assignment operator (aassign) to be used instead of a scalar assignment operator (sassign).

    I can't follow your interpretation ... aassign implies listcontext! 

      DB<54> $a= join ",",(1..5)


  DB<55> p $a
1,2,3,4,5

  DB<56> print scalar split /,/,$a
5

  DB<57> ($A)=split /,/,$a


  DB<58> print $A
1

    [download]
    split is executed in listcontext!

    Cheers Rolf

[reply]
[d/l]

      Yes, operators determine the context in which their operands are evaluated, and the aassign operator unconditionally evaluates its operands in list context. It's not based on the presence or absence of parens.

      You previously said that the operand ("($a)") determined the context. An expression never decides the context in which its evaluated. The context in which its evaluated is always imposed upon it by its caller.

      Even at the abstract level, the reason for using "($a)=" instead of "$a=" isn't to evaluate $a in list context. After all, $a evaluates to the same thing in both list and scalar context. The goal is to use the list assignment operator.

[reply]
[d/l]
[select]

        I'm not so sure about that. My recollection was that assignment determined it's context by the left-hand side of the operation. A quick test 

        sub which
{ 
   if(wantarray)
   {
       print "list\n"; ();
   }
   else
   {
      "scalar\n"; 0;
   }
}

my $a = which();
my ($b) = which();

        [download]

        seems to confirm this suspicion. The first prints scalar and the second prints list. This seems to imply that the subroutine is evaluated in scalar context in the first assignment.

        Is there something I'm missing?

        G. Wade
[reply]
[d/l]
[select]
        Sorry many words I don't understand...

        ($a)= puts the RHS in listcontext,

        $a= puts the RHS in scalarcontext

        it's alway the same "=" and of course $a is a scalar.

        you said

        > The parens in ($a)=@_ don't affect context

        > Except when empty, parens never do more than control precedence. Except when empty, they never create a list context.

        The code shows your wrong that perl syntax is more complex. But if I'm wrong, please give me a reference to a perldoc defining "listcontext" the way your understanding it!

        Cheers Rolf

        UPDATE: to make it clear, I'm not saying that $a is evaluated in list-context, but I think it's reasonable to say that the LHS ($a) is a one element list, where commas were saved, like () is a null element list. If not please show me code that showes that ($a) is not a list.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom