Re^5: poll ideas quest 2021

unquoted hash keys on the left of the fat comma

That will rule out a lot of the Perl I read and pretty much all of the Perl I write. If that's a policy restriction rather than a technical one then I am at a loss to understand the reasoning behind it.

🦛

Comment on Re^5: poll ideas quest 2021

Replies are listed 'Best First'.
Re^6: poll ideas quest 2021 by haukex (Archbishop) on Aug 18, 2021 at 08:42 UTC
That will rule out a lot of the Perl I read and pretty much all of the Perl I write. Yes, same here, and I commented on that in the issue I linked to above and Sawyer responded here. It doesn't seem to be a technical limitation. Since I think it would be technically possible to parse something like `my %hash = ( foo => -bar );`, that also means that it would be possible to automatically transform that to `my %hash = ( 'foo' => '-bar' );`, for example if that's what the company coding standards happen to be. Update: However, the transformation requires a completely parseable Perl in the first place, which is what we don't have (yet).	[reply] [d/l] [select]
Re^7: poll ideas quest 2021 by Corion (Patriarch) on Aug 18, 2021 at 08:45 UTC
I think the problem with `-bar` is that it is difficult to disambiguate between the expression `'-' bareword` and `'-bareword'` as a single token. Maybe you can fix that by post-processing the generated tree, but my impression is that Sawyer wanted to avoid any "special" logic and have a purely EBNF-driven approach.	[reply] [d/l] [select]
Re^8: poll ideas quest 2021 by haukex (Archbishop) on Aug 18, 2021 at 08:51 UTC
I think the problem with `-bar` is that it is difficult to disambiguate between the expression `'-' bareword` and `'-bareword'` as a single token. Hmmm... you mean like `-bareword` and `-function_call`? Since standard requires parens on function calls, which is something I understand is probably going to be necessary for parseability, wouldn't that disambiguate the two? Or do you have another counterexample in mind?	[reply] [d/l] [select]