inconsistent block/hash detection (again)

[p5pRT]

Migrated from rt.perl.org#130958 (status was 'resolved')

Searchable as RT130958$

[p5pRT]

From @rjbs

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

[p5pRT]

From @iabyn

On Wed, Mar 08, 2017 at 11​:13​:03AM -0800, Ricardo SIGNES wrote​:

# 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-archive.perl.org/perl5/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)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @rjbs

* 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. :/

--
rjbs

[p5pRT]

From @xsawyerx

On 07/07/2017 04​:46 PM, Ricardo Signes wrote​:

* 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
  }
  ];

[p5pRT]

From zefram@fysh.org

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.

-zefram

[p5pRT]

From @demerphq

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.

Yves

[p5pRT]

From @Abigail

On Tue, Jul 11, 2017 at 07​:05​:34PM +0200, demerphq wrote​:

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

[p5pRT]

From zefram@fysh.org

I wrote​:

                                                            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 5577141. That should satisfy
this ticket.

-zefram

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'