Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistent block/hash detection (again) #15918

Closed
p5pRT opened this issue Mar 8, 2017 · 10 comments
Closed

inconsistent block/hash detection (again) #15918

p5pRT opened this issue Mar 8, 2017 · 10 comments
Labels

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Mar 8, 2017

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

Searchable as RT130958$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 8, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 29, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 29, 2017

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 7, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 10, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 10, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 11, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 24, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 5, 2017

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
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 8, 2017

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

@p5pRT p5pRT closed this Dec 8, 2017
@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.