Skip Menu |
Report information
Id: 130958
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: rjbs <rjbs [at] cpan.org>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: inconsistent block/hash detection (again)
From: Ricardo Signes <rjbs [...] cpan.org>
To: perlbug [...] perl.org
Date: Wed, 8 Mar 2017 14:12:32 -0500
Download (untitled) / with headers
text/plain 756b
I realize that the block/hash issue has had a lot of ink spilled over it, but this particular example surprised and baffled me (and Matthew Horsfall, who pointed it out to me today): ~$ perl -MData::Dumper -E 'say Dumper([ map {; { 1 => $_ } } qw(cat) ])' $VAR1 = [ { '1' => 'cat' } ]; ~$ perl -MData::Dumper -E 'say Dumper([ map {; { $_ => 1 } } qw(cat) ])' $VAR1 = [ 'cat', 1 ]; The inside {...} in these two are interpreted differently based on whether the first token is $_ or 1? On one hand, I wish these were consistent. On the other, I realize that this change might break some code somewhere. (Yes, I know you can force the issue with a unary plus.) -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

To: perl5-porters [...] perl.org
Subject: Re: [perl #130958] inconsistent block/hash detection (again)
From: Dave Mitchell <davem [...] iabyn.com>
Date: Wed, 29 Mar 2017 14:02:57 +0100
Download (untitled) / with headers
text/plain 1.3k
On Wed, Mar 08, 2017 at 11:13:03AM -0800, Ricardo SIGNES wrote: Show quoted text
> # New Ticket Created by Ricardo SIGNES > # Please include the string: [perl #130958] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=130958 > > > > I realize that the block/hash issue has had a lot of ink spilled over it, but > this particular example surprised and baffled me (and Matthew Horsfall, who > pointed it out to me today): > > ~$ perl -MData::Dumper -E 'say Dumper([ map {; { 1 => $_ } } qw(cat) ])' > $VAR1 = [ > { > '1' => 'cat' > } > ]; > > ~$ perl -MData::Dumper -E 'say Dumper([ map {; { $_ => 1 } } qw(cat) ])' > $VAR1 = [ > 'cat', > 1 > ]; > > The inside {...} in these two are interpreted differently based on whether the > first token is $_ or 1? On one hand, I wish these were consistent. On the > other, I realize that this change might break some code somewhere.
I don't see that as being particularly surprising. The rule appears to be: if a literal constant follows the '{' it's probably a hash; if a variable follows the '{' its probably a block. -- Little fly, thy summer's play my thoughtless hand has terminated with extreme prejudice. (with apologies to William Blake)
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Fri, 7 Jul 2017 16:46:03 -0400
CC: perl5-porters [...] perl.org
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #130958] inconsistent block/hash detection (again)
Download (untitled) / with headers
text/plain 843b
* Dave Mitchell <davem@iabyn.com> [2017-03-29T09:02:57] Show quoted text
> > The inside {...} in these two are interpreted differently based on whether > > the first token is $_ or 1? On one hand, I wish these were consistent. On > > the other, I realize that this change might break some code somewhere.
> > I don't see that as being particularly surprising. The rule appears to be: > if a literal constant follows the '{' it's probably a hash; if a variable > follows the '{' its probably a block.
I guess the reason I was surprised is that I don't know what the rule is, nor could I find an explanation. I suppose I don't have any actual constructive suggestion to make, and maybe I should just henceforth write +{ much more often. If nobody else has a good idea for making this clearer in docs or anything else, let's close this ticket. :/ -- rjbs
CC: perl5-porters [...] perl.org
Date: Mon, 10 Jul 2017 12:54:13 -0400
From: Sawyer X <xsawyerx [...] gmail.com>
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #130958] inconsistent block/hash detection (again)
Download (untitled) / with headers
text/plain 1.1k
On 07/07/2017 04:46 PM, Ricardo Signes wrote: Show quoted text
> * Dave Mitchell <davem@iabyn.com> [2017-03-29T09:02:57]
>>> The inside {...} in these two are interpreted differently based on whether >>> the first token is $_ or 1? On one hand, I wish these were consistent. On >>> the other, I realize that this change might break some code somewhere.
>> I don't see that as being particularly surprising. The rule appears to be: >> if a literal constant follows the '{' it's probably a hash; if a variable >> follows the '{' its probably a block.
> I guess the reason I was surprised is that I don't know what the rule is, nor > could I find an explanation. I suppose I don't have any actual constructive > suggestion to make, and maybe I should just henceforth write +{ much more > often. > > If nobody else has a good idea for making this clearer in docs or anything > else, let's close this ticket. :/
There's no reason to not make it clearer in the docs. Or, rephrasing: let's make it clearer in the docs. No harm in that. Also: $ perl -MData::Dumper -E 'say Dumper([ map {; { "$_" => 1 } } qw(cat) ])' $VAR1 = [ { 'cat' => 1 } ];
Subject: Re: [perl #130958] inconsistent block/hash detection (again)
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Mon, 10 Jul 2017 23:21:06 +0100
Download (untitled) / with headers
text/plain 370b
Ricardo Signes wrote: Show quoted text
>I guess the reason I was surprised is that I don't know what the rule is, nor >could I find an explanation.
The actual rule is hideous. We shouldn't attempt to explain it; we should just document clearly how to force the interpretation ("+{" and "{;"). We should also not make any change to the rule, for fear of breaking correct code. -zefram
CC: Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Date: Tue, 11 Jul 2017 19:05:34 +0200
Subject: Re: [perl #130958] inconsistent block/hash detection (again)
To: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 456b


On 11 Jul 2017 00:22, "Zefram" <zefram@fysh.org> wrote:
Show quoted text
Ricardo Signes wrote:
>I guess the reason I was surprised is that I don't know what the rule is, nor
>could I find an explanation.

The actual rule is hideous.  We shouldn't attempt to explain it; we should
just document clearly how to force the interpretation ("+{" and "{;").
We should also not make any change to the rule, for fear of breaking
correct code.

Hear hear. Abigail does this. 

Yves
Show quoted text


Subject: Re: [perl #130958] inconsistent block/hash detection (again)
From: Abigail <abigail [...] abigail.be>
Date: Thu, 24 Aug 2017 14:29:58 +0200
CC: Zefram <zefram [...] fysh.org>, Perl5 Porteros <perl5-porters [...] perl.org>
To: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 625b
On Tue, Jul 11, 2017 at 07:05:34PM +0200, demerphq wrote: Show quoted text
> On 11 Jul 2017 00:22, "Zefram" <zefram@fysh.org> wrote: > > Ricardo Signes wrote:
> >I guess the reason I was surprised is that I don't know what the rule is,
> nor
> >could I find an explanation.
> > The actual rule is hideous. We shouldn't attempt to explain it; we should > just document clearly how to force the interpretation ("+{" and "{;"). > We should also not make any change to the rule, for fear of breaking > correct code. > > > Hear hear. Abigail does this. >
Only when Perl gets it wrong, of if I'm not sure Perl will get it right. Abigail
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #130958] inconsistent block/hash detection (again)
Date: Tue, 5 Dec 2017 20:57:03 +0000
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 396b
I wrote: Show quoted text
> we should >just document clearly how to force the interpretation ("+{" and "{;").
This is already documented pretty clearly in perlref(1). I've added a similar note to perlsyn(1), where it introduces the concept of a block, in commit 557714184de18964b954b2c00fa13127fd3f216a. That should satisfy this ticket. -zefram


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org