Re^2: statement vs. block?

That's because your map line is being parsed as map($_, $_) which is assigned to @y, followed by the array @short in void context (i.e. B::Deparse with the appropriate flags says ((my(@y) = map($_, $_)), @short);). If you disambiguate with a + (my @z = map +($_, $_), @short;) or explicitly parenthesize where map's arguments end (my @w = map( ($_, $_), @short );) it'll be parsed correctly ((my(@z) = map(($_, $_), @short));).

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

Comment on Re^2: statement vs. block? Select or Download Code

Replies are listed 'Best First'.
Re^3: statement vs. block? by kyle (Abbot) on Apr 11, 2008 at 23:55 UTC
Maybe I'm not getting what the OP is asking for. I read "any piece of code that would run unchanged as a statement or a block, that would behave differently in one relative to the other" as some stuff such that "`map {`stuff `} @any`" doesn't do the same thing as "`map`stuff`, @any`" (but does run). I provided that.	[reply] [d/l] [select]
Re^4: statement vs. block? by Fletch (Bishop) on Apr 12, 2008 at 00:13 UTC
Right, but the difference in your example is because of the precedence affecting powers of parens. Your examples have fallen afoul of the "if it looks like a function call it is one" rule (see perlfunc). It's the difference between `print (42+23)2;` and `print +(42+23)2;`; the parens change where the LIST of arguments to the list operator begin. (Not that you're wrong; it is a case where the literal code is different. I just wanted to point out that the difference is because of what the actual parsed code works out to be rather than it being that stuff is behaving different as `map EXPR, LIST` versus how `map BLOCK LIST` would, which I think was what's being asked.) The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]