Re^5: poll ideas quest 2021

[hippo]

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.

[haukex]

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).

[Corion]

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.

[haukex]

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?