-
Notifications
You must be signed in to change notification settings - Fork 561
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
Double quotes in map call induce a syntax error #14781
Comments
From the.rob.dixon@gmail.comThis is a bug report for perl from the.rob.dixon@gmail.com, There is a strange issue with double-quoted variables when using `map` This is fine %h = map { $k => 1 } 1; but this %h = map { "$k" => 1 } 1; throws a syntax error 'near "} 1"' Flags: Site configuration information for perl 5.22.0: Configured by strawberry-perl at Mon Jun 1 20:06:45 2015. Summary of my perl5 (revision 5 version 22 subversion 0) configuration: Platform: @INC for perl 5.22.0: Environment for perl 5.22.0: PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ffmpeg\bin;C:\Program |
From @ilmariRob Dixon (via RT) <perlbug-followup@perl.org> writes:
This is documented in the perlfunc entry for map: { starts both hash references and blocks, so map { ... could be %hash = map { "\L$_" => 1 } @array # perl guesses EXPR. wrong %hash = map ( lc($_), 1 ), @array # evaluates to (1, @array) http://perldoc.perl.org/functions/map.html -- |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgRob Dixon wrote:
Not specific to map: $ perl -le '{ $k => 1 } 1; print "OK"' The difference in parsing is whether the braced group is interpreted as $ perl -le '{ $k => 1 } ^ 1; print "OK"' This problem arises anywhere that the next thing can be either a code $ perl -le '{; $k => 1 } 1; print "OK"' -zefram |
From cm.perl@abtela.comLe 01/07/2015 17:50, Rob Dixon (via RT) a écrit :
Not a bug IMO. This is because of the inherent ambiguity of { ... } as either an Perl does not always succeed in guessing the intended nature of the You can force the block interpretation by adding a semicolumn after the $ perl -MData::Dump -E'%h = map {; "$k" => 1 } 1; dd \%h'; --Christian |
From perl5-porters@perl.orgChristian Millour wrote:
No, but it is a fixable misfeature. |
From zefram@fysh.orgFather Chrysostomos wrote:
It's impossible to always disambiguate correctly, where the ambiguity What we *can* improve is the error message. We could tag the braced The other fixing that's conceivable is to remove some cases of the -zefram |
From @rjbs* Zefram <zefram@fysh.org> [2015-07-01T16:01:09]
I was just wondering whether anybody but rjbs would benefit from something like Would we want to enforce it on new users? Well, I'd put it in the style guide Anyway, I think that a better diagnostic on these cases would be just great. -- |
From @AbigailOn Wed, Jul 01, 2015 at 04:17:03PM -0400, Ricardo Signes wrote:
I almost always use "map {BLOCK} LIST" as well, unless I really need
I've encountered enough people who prefer "map EXPR, LIST" over
That I fully support. [1] At $WORK we used to have hot code where this difference mattered -- Abigail |
From @ap* Zefram <zefram@fysh.org> [2015-07-01 22:05]:
Yes please! That would be excellent. * Ricardo Signes <perl.p5p@rjbs.manxome.org> [2015-07-01 22:20]:
I do prefer `map BLOCK` but still use `map EXPR` liberally. If I’m mapping to a short expression, the extra braces feel like an I was going to say I still use `map BLOCK` far more, but then I ran Also, I knew I don’t use the `map {;` disambiguation all the time, but But, conversely, when I do mean to map each list element to a hash, Obviously I would never object to some kind of optional `no mapexpr` Regards, |
From @epaYou could tweak the DWIMmery slightly so that a map call is always assumed These (not-a-)bugs come up quite often. -- |
From @AbigailOn Thu, Jul 02, 2015 at 07:21:59AM +0000, Ed Avis wrote:
Changing the current behaviour runs the risk of breaking existing It's a trade-off I prefer not to change.
Abigail |
From cm.perl@abtela.comLe 01/07/2015 22:44, Abigail a écrit :
Interesting. I was led to believe that postfix foreach was faster than $ /usr/local/bin/perl -MBenchmark=timethese,cmpthese -E' and ranges $ /usr/local/bin/perl -MBenchmark=timethese,cmpthese -E' I have experimented with list sizes ranging from 10 to 100_000 with TIA, --Christian, (FWIW, the benchmarks above were run on an old but very lightly used $ /usr/local/bin/perl -V Platform: Characteristics of this binary (from libperl): |
From @AbigailOn Thu, Jul 02, 2015 at 01:44:35PM +0200, Christian Millour wrote:
All you have proven is that for this particular expression, on your Things may be different if you have a different OS, a different version If it matters, always benchmark what you're actually doing, under real Abigail |
From cm.perl@abtela.comLe 02/07/2015 13:58, Abigail a écrit :
To be honest I am not familiar with Benchmark.pm. I tried to mitigate
Definitely, and my question was in no way a rebuttal or your own This has impacted my programming style : I tend to favor postfix
amen to that :-). Cheers, --Christian
|
Migrated from rt.perl.org#125522 (status was 'open')
Searchable as RT125522$
The text was updated successfully, but these errors were encountered: