search

Perl / perl5

đŸȘ The Perl programming language
https://dev.perl.org/perl5/
Other
1.91k stars 542 forks source link

suppress warning on using unquoted strings in {} in slices too #12099

Closed p5pRT closed 12 years ago

p5pRT commented 12 years ago

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

Searchable as RT112914$

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I might consider this a wish list item\, but from the standpoint of consistency\, I am filing as a low-prio/low-severity bug... If you wanna change it\, no prob.

From the wording in perldata\, and for the sake of consistency this seems like it should not issue a warning nor be a potential candidate for reserved word interpretation.

perl -wE 'my $p={};my ($dat\, $tim) = @​{$p}{dat\,tim};' Unquoted string "dat" may clash with future reserved word at -e line 1. Unquoted string "tim" may clash with future reserved word at -e line 1.

From perldata\, "an identifier within such curlies is forced to be a string\, as is any simple identifier within a hash subscript. So if the above recognizes that 'dat' and 'tim' are simple identifiers (which it seems to by acknowledging them 2 parseable entities and not the single entity 'dat\,tim'\, then it would seem that\, as in a single hash\, $days{Feb}"\, keynames should not require quotes.

Currently\, a workaround for a hash slice would be to enclose the hash terms in qw(key1 key2 key3) in the braces\, but that's a bit ugly.

Perl Info ``` Flags: category=core severity=low This perlbug was built using Perl 5.14.2 - Sat Oct 29 15:59:10 UTC 2011 It is being executed now by Perl 5.14.2 - Sat Oct 29 15:55:30 UTC 2011. Site configuration information for perl 5.14.2: Configured by abuild at Sat Oct 29 15:55:30 UTC 2011. Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=linux, osvers=3.1.0-rc10-1-default, archname=x86_64-linux-thread-multi uname='linux build33 3.1.0-rc10-1-default #1 smp thu oct 20 08:17:26 utc 2011 (f6d77d4) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.6.2', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.14.1.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.14.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.14.2: /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl . Environment for perl 5.14.2: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/sbin:/usr/local/sbin:/opt/lsb/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib:/home/law/bin/lib PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 12 years ago

From @cpansprout

On Sun May 13 14​:53​:26 2012\, LAWalsh wrote​:

I might consider this a wish list item\, but from the standpoint of consistency\, I am filing as a low-prio/low-severity bug... If you wanna change it\, no prob.

From the wording in perldata\, and for the sake of consistency this seems like it should not issue a warning nor be a potential candidate for reserved word interpretation.

perl -wE 'my $p={};my ($dat\, $tim) = @​{$p}{dat\,tim};' Unquoted string "dat" may clash with future reserved word at -e line 1. Unquoted string "tim" may clash with future reserved word at -e line 1.

From perldata\, "an identifier within such curlies is forced to be a string\, as is any simple identifier within a hash subscript. So if the above recognizes that 'dat' and 'tim' are simple identifiers (which it seems to by acknowledging them 2 parseable entities and not the single entity 'dat\,tim'\, then it would seem that\, as in a single hash\, $days{Feb}"\, keynames should not require quotes.

Currently\, a workaround for a hash slice would be to enclose the hash terms in qw(key1 key2 key3) in the braces\, but that's a bit ugly.

In that instance\, if you have a sub named tim\, then @​hash{dat\,tim} will call the sub.

I would suggest a clarification to the documentation​:

Inline Patch ```diff diff --git a/pod/perldata.pod b/pod/perldata.pod index 876382d..aa532f7 100644 --- a/pod/perldata.pod +++ b/pod/perldata.pod @@ -355,7 +355,7 @@ C<$who::0>, and a C<$who's> variable. The last two ```

would be the $0 and the $s variables in the (presumably) non-existent package C\.

-In fact\, an identifier within such curlies is forced to be a string\, +In fact\, a single identifier within such curlies is forced to be a string\, as is any simple identifier within a hash subscript. Neither need quoting. Our earlier example\, C\<$days{'Feb'}> can be written as C\<$days{Feb}> and the quotes will be assumed automatically. But

--

Father Chrysostomos

p5pRT commented 12 years ago

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

p5pRT commented 12 years ago

From @ap

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2012-05-14 02​:50]​:

I would suggest a clarification to the documentation​:

-In fact\, an identifier within such curlies is forced to be a string\, +In fact\, a single identifier within such curlies is forced to be a string\, as is any simple identifier within a hash subscript. Neither need

The surrounding text consistently uses “simple identifier” to refer to this case\, such as right on the next line. In fact the mention on the next line arguably addresses the specific case that Linda W was confused about\, so it is can be argued that the behaviour and its documentation are both correct and consistent with each other already i.e. nothing needs to be done at all


But if something were to be\, I would suggest some additional editing to reduce verbosity​:

Inline Patch ```diff diff --git i/pod/perldata.pod w/pod/perldata.pod index 876382d..eafdc84 100644 --- i/pod/perldata.pod +++ w/pod/perldata.pod @@ -355,8 +355,8 @@ C<$who::0>, and a C<$who's> variable. The last two would be the $0 and the $s variables in the (presumably) non-existent package C. -In fact, an identifier within such curlies is forced to be a string, -as is any simple identifier within a hash subscript. Neither need +In fact, a simple identifier within such curlies is forced to be +a string, and likewise within a hash subscript. Neither need quoting. Our earlier example, C<$days{'Feb'}> can be written as C<$days{Feb}> and the quotes will be assumed automatically. But anything more complicated in the subscript will be interpreted as an ```
p5pRT commented 12 years ago

From perl-diddler@tlinx.org

A. Pagaltzis via RT wrote​:

* Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org [2012-05-14 02​:50]​:

I would suggest a clarification to the documentation​:

-In fact\, an identifier within such curlies is forced to be a string\, +In fact\, a single identifier within such curlies is forced to be a string\, as is any simple identifier within a hash subscript. Neither need

The surrounding text consistently uses “simple identifier” to refer to this case\, such as right on the next line. In fact the mention on the next line arguably addresses the specific case that Linda W was confused about\, so it is can be argued that the behaviour and its documentation are both correct and consistent with each other already i.e. nothing needs to be done at all


So when there are commas separating elements in the list\, single quotes are required?

As in​: my $rec = {   a => 1\,   b => 2\,   c => 3\,   };

Are both of you saying the above construct\, which perl DOESN'T complain about\, is unsafe?

Let me try this...

perl -wE ' sub dat(){"bad"}; my $p={bad=>"18010112"\, dat=>"20120520"\,tim=>"0701"}; my ($dat\, $tim) = @​{$p}{dat=>tim}; print "dat=$dat\, tim=$tim\n"; ' Unquoted string "tim" may clash with future reserved word at -e line 4. dat=20120520\, tim=0701

Hey\, looks like a non-simple var in {} is permitted\, as long as it's => so a hash like {a=>b=>c=>d=>} is fine -- and just like nothing is needed between a last comma and brace\, the same holds here...

funny how I was always taught that => and \, are synonymous... Seems that's changed.

putting => to the right of a term is the same as quoting it... That would still make the quoted section a bit lacking..

FWIW\, if you use "\," to separate dat/tim in the hash\, the printed value is 18010112...

I take it\, that the protection of "=>" of it's left-hand operator went in at the same time as the removal of need for quotes in braces around a single identifier?

So now in initializing a hash\, that means\, you are treating half the elements unequally\, (or all of them if you use multiple =>?)

It seems that the same problem existed in initialization statements as now exists in hash slices. Yet it was decided that key names would be interpreted statically. Is that able to be overridden with a & to specify a function? --- if not\, it seems that concern over someone having a function by the same name as a key was considered not only negligible\, but something that could be "thrown out".

It seems the decision was made to treat keys statically -- can you come up with any argument supporting the use of function output for a slice that couldn't be made for an initialization statement?

I.e. it would seem seem they should be treated similarly without the need for a "feature" of using => to side-quote it's left operand.

Or are we going to see '=>' documented as a way to quote keynames in slices as well? *hmmm*...

FWIW... I just want to not to have to use quotes for keynames.. going that route for $A{X} and ${A=>X} was great! makes the code look better -- but the same problem of ugly exists in slices...

Given that the insides of {} for a non-notated identifier can't be other than a simple string\, can not doing the same for slices be justified?

p5pRT commented 12 years ago

From mailinglisten@renee-baecker.de

On 14.05.2012 11​:27\, Linda W wrote​:

Let me try this...

perl -wE ' sub dat(){"bad"}; my $p={bad=>"18010112"\, dat=>"20120520"\,tim=>"0701"}; my ($dat\, $tim) = @​{$p}{dat=>tim}; print "dat=$dat\, tim=$tim\n"; ' Unquoted string "tim" may clash with future reserved word at -e line 4. dat=20120520\, tim=0701

Hey\, looks like a non-simple var in {} is permitted\, as long as it's => so a hash like {a=>b=>c=>d=>} is fine -- and just like nothing is needed between a last comma and brace\, the same holds here...

funny how I was always taught that => and \, are synonymous... Seems that's changed.

This is documented in perlop​:

The |=>| operator is a synonym for the comma except that it causes its left operand to be interpreted as a string if it begins with a letter or underscore and is composed only of letters\, digits and underscores. This includes operands that might otherwise be interpreted as operators\, constants\, single number v-strings or function calls. If in doubt about this behavior\, the left operand can be quoted explicitly.

Otherwise\, the |=>| operator behaves exactly as the comma operator or list argument separator\, according to context.

p5pRT commented 12 years ago

From mailinglisten@renee-baecker.de

On 14.05.2012 12​:17\, RenĂ©e BĂ€cker wrote​:

On 14.05.2012 11​:27\, Linda W wrote​:

Let me try this...

perl -wE ' sub dat(){"bad"}; my $p={bad=>"18010112"\, dat=>"20120520"\,tim=>"0701"}; my ($dat\, $tim) = @​{$p}{dat=>tim}; print "dat=$dat\, tim=$tim\n"; ' Unquoted string "tim" may clash with future reserved word at -e line 4. dat=20120520\, tim=0701

Hey\, looks like a non-simple var in {} is permitted\, as long as it's => so a hash like {a=>b=>c=>d=>} is fine -- and just like nothing is needed between a last comma and brace\, the same holds here...

funny how I was always taught that => and \, are synonymous... Seems that's changed.

This is documented in perlop​:

The |=>| operator is a synonym for the comma except that it causes its left operand to be interpreted as a string if it begins with a letter or underscore and is composed only of letters\, digits and underscores. This includes operands that might otherwise be interpreted as operators\, constants\, single number v-strings or function calls. If in doubt about this behavior\, the left operand can be quoted explicitly.

Otherwise\, the |=>| operator behaves exactly as the comma operator or list argument separator\, according to context.

Arghh\, copying from perldoc.perl.org added the "|". It should be

This is documented in perlop​:

The => operator is a synonym for the comma except that it causes its left operand to be interpreted as a string if it begins with a letter or underscore and is composed only of letters\, digits and underscores. This includes operands that might otherwise be interpreted as operators\, constants\, single number v-strings or function calls. If in doubt about this behavior\, the left operand can be quoted explicitly.

Otherwise\, the => operator behaves exactly as the comma operator or list argument separator\, according to context.

p5pRT commented 12 years ago

From @rjbs

I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0

p5pRT commented 12 years ago

@rjbs - Status changed from 'open' to 'rejected'

p5pRT commented 12 years ago

From @rjbs

I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0

p5pRT commented 12 years ago

From @shadowcat-mst

So when there are commas separating elements in the list\, single quotes are required?

The key thing to remember is that => is a comma that autoquotes its left hand side if its left hand side is a valid bareword.

So given a valid bareword to the left of an =>\, it does not need quoting. Perl already does so.

Whether a comma is used further on to separate later elements doesn't affect this - could you point out which specific part of the documentation leaves this unclear to you and suggest a rewording?

my ($dat\, $tim) = @​{$p}{dat=>tim};

Here\, since the dat is to the left of the => and is a valid bareword\, it's autoquoted; if you wanted the output of the dat() function then yes\, you could use & but I'd rather write it

  my ($dat\, $time) = @​{$p}{dat()=>'tim'};

(bear in mind that strict will simply refuse to accept the unquoted tim before you get as far as worrying about possible clashes with future reserved names).

funny how I was always taught that => and \, are synonymous... Seems that's changed.

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

It's worth remembering though that while -foo is not a valid bareword\, unary minus when applied to a string prepends a - to it - hence

  -'foo'

returns

  "-foo"

although the single quotes are optional since the parsing for unary minus will implicitly quote a *following* bareword in the same way that => implicitly quotes a *preceding* one.

It seems the decision was made to treat keys statically -- can you come up with any argument supporting the use of function output for a slice that couldn't be made for an initialization statement?

I'm not sure what you mean by "statically" here - rather than a description rendered in words (which as this thread demonstrates\, can be interpreted in all sorts of ways) could you provide a set of concrete examples to illustrate your point?

Or are we going to see '=>' documented as a way to quote keynames in slices as well? *hmmm*...

I don't see any such patch currently pending\, so I'd imagine that the answer is that we definitely will not unless somebody writes one - and I'm not really sure that it would be a good idea. Once you're providing multiple keys\, i.e. multiple words or word-like things that you don't want to have to quote individually\, then

  @​{$p}{qw(dat tim)}

is no more typing than two => would be and generalises nicely - and as soon as you get to three or more keys in the slice is absolutely less typing\, so that seems like a better thing for the documentation to suggest.

Given that the insides of {} for a non-notated identifier can't be other than a simple string\, can not doing the same for slices be justified?

I'm not entirely sure what you're trying to suggest here; in the case of a hash slice\, the contents of the {} is a list\, not a single identifier\, so I don't really see how there's a "the same" to do.

What syntax did you have in mind\, and why do you consider it superior to the qw() approach I showed above?

If it's simply that the qw() approach isn't documented sufficiently obviously\, could you please have a think about where you looked for this information that didn't contain it? The trouble with documentation omissions is that once you've learned the relevant technique from somewhere else\, it's effectively impossible to detect the omission when reading the documentation that omits the technique - so it behooves the person suffering from the omission to identify it specifically if they want it to be remedied.

If you could suggest what additional examples or additional text would assist with the clarification of any of these\, that would be much appreciated\, although simply pointing out where such examples might be worth adding would be an excellent start.

If you make a first cut at an appropriate patch (even if it initially just adds XXX marks to the places you think need additional examples) then I'd be happy to go over it with you and answer any additional clarification questions involved; I'm quite conscious that the perl documentation is rather terse in places\, and much though I rather like the old school man page style\, I'm sympathetic to the confusion it can cause for people who haven't read and internalised the entire thing. "Terse"\, fortunately\, doesn't seem to be something you suffer overly from\, so given you have the viewpoint\, the incentive and the capacity to produce such a patch and I as a not-confused-by-this person don't I'd be happy to trade technical specifics for your unique capacities.

What say you?

-- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http​://shadowcat.co.uk/blog/matt-s-trout/ http​://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support\, training and consultancy packages could help your team.

p5pRT commented 12 years ago

From @tux

On Mon\, 14 May 2012 14​:18​:44 +0100\, Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote​:

my ($dat\, $tim) = @​{$p}{dat=>tim};

Here\, since the dat is to the left of the => and is a valid bareword\, it's autoquoted; if you wanted the output of the dat() function then yes\, you could use & but I'd rather write it

my ($dat\, $time) = @​{$p}{dat()=>'tim'};

Or use abigails

  my ($dat\, $time) = @​{$p}{ dat \,=> "tim");

In hash creation\, => is as \, with auto-quoting the lefthand when it is a bareword. Adding an extra comma disables the auto-quoting but keeps the visual effect a fat comma gives for key-value pairs

(bear in mind that strict will simply refuse to accept the unquoted tim before you get as far as worrying about possible clashes with future reserved names).

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 06​:19​:31 2012\, mst@​shadowcat.co.uk wrote​:

So when there are commas separating elements in the list\, single quotes are required?

The key thing to remember is that => is a comma that autoquotes its left hand side if its left hand side is a valid bareword.

So given a valid bareword to the left of an =>\, it does not need quoting. Perl already does so.

Whether a comma is used further on to separate later elements doesn't affect this - could you point out which specific part of the documentation leaves this unclear to you and suggest a rewording?

my ($dat\, $tim) = @​{$p}{dat=>tim};

Here\, since the dat is to the left of the => and is a valid bareword\, it's autoquoted; if you wanted the output of the dat() function then yes\, you could use & but I'd rather write it

my ($dat\, $time) = @​{$p}{dat()=>'tim'};

(bear in mind that strict will simply refuse to accept the unquoted tim before you get as far as worrying about possible clashes with future reserved names).

funny how I was always taught that => and \, are synonymous... Seems that's changed.

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

It's worth remembering though that while -foo is not a valid bareword\, unary minus when applied to a string prepends a - to it - hence

-'foo'

returns

"-foo"

although the single quotes are optional since the parsing for unary minus will implicitly quote a *following* bareword in the same way that => implicitly quotes a *preceding* one.

It doesn’t autoquote it\, but simply exempts it from strictures. -time is the current time negated\, not "-time".

--

Father Chrysostomos

p5pRT commented 12 years ago

From @ikegami

On Mon\, May 14\, 2012 at 5​:27 AM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

** So when there are commas separating elements in the list\, single quotes are required?

As in​: my $rec = { a => 1\, b => 2\, c => 3\, };

No.

$h{ dat => tim => };

is perfectly safe.

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators in a *slice* in the same way that could not also be used as reasoning to disallow such interpretation in the places it is now allowed\, i.e. ${xx} or to left of "=>" ?

Matt wrote​:

my ($dat\, $time) = @​{$p}{dat()=>'tim'};

(bear in mind that strict will simply refuse to accept the unquoted tim before you get as far as worrying about possible clashes with future reserved names).

  my ($date\, $time\, $origin) = @​{$p}{dat => tim => org => }

  You need to follow your final 'tim' with a "\," to keep strict happy.  
  When anyone asks bout constructs that list several key's with => after them like in the above\, I think it would be useful to only useful to point them to the sections in perlop on => and perldata on slices\, for them to see examples of the above being the parallel way to specify keys for slices as { key => data } is for initializations.

  Prior to this I have been using qw()\, but for few items it tends to look overly busy (not that they above is real attractive\, but if that's the approved perl way...)...

  Personally\, I'd like to see a way -- *if possible* to treat bareword keys between separators in a slice\, as bareword strings by default\, as that seems to be the more common usage case. Again\, I point to my initial paragraph. Why shouldn't it be that way to be consistent with other usages of bareword keys? (other than "we don't wanna")

p5pRT commented 12 years ago

From @ikegami

On Mon\, May 14\, 2012 at 12​:06 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators

There's no "seperators"\, just a single expression.

Your suggestion would break this code​:

$ perl -E'sub f { "a"\, "b" } sub g { "c"\, "d" } my %h = map { $_ => $_ } "a".."z"; say @​h{f\, g};' abcd

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 09​:07​:12 2012\, LAWalsh wrote​:

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators in a *slice* in the same way that could not also be used as reasoning to disallow such interpretation in the places it is now allowed\, i.e. ${xx} or to left of "=>" ?

Matt wrote​:

my ($dat\, $time) = @​{$p}{dat()=>'tim'};

(bear in mind that strict will simply refuse to accept the unquoted tim before you get as far as worrying about possible clashes with future reserved names).

my ($date\, $time\, $origin) = @​{$p}{dat => tim => org => }

You need to follow your final 'tim' with a "\," to keep strict happy\.

When anyone asks bout constructs that list several key's with

=> after them like in the above\, I think it would be useful to only useful to point them to the sections in perlop on => and perldata on slices\, for them to see examples of the above being the parallel way to specify keys for slices as { key => data } is for initializations.

Prior to this I have been using qw\(\)\, but for few items it tends

to look overly busy (not that they above is real attractive\, but if that's the approved perl way...)...

Personally\, I'd like to see a way \-\- \*if possible\* to treat bareword

keys between separators in a slice\, as bareword strings by default\, as that seems to be the more common usage case. Again\, I point to my initial paragraph. Why shouldn't it be that way to be consistent with other usages of bareword keys? (other than "we don't wanna")

It’s conceptually simpler the way it is​: bareword or expression. If it’s not a single bareword\, then it’s an expression parsed the same way expressions are parsed anywhere else.

Your suggestion would be​: bareword\, comma-separated list of barewords\, or expression. The second item in that list would be a new species unique to this construct.

I don’t think the resulting conceptual complexity is worth it.

--

Father Chrysostomos

p5pRT commented 12 years ago

From @iabyn

On Mon\, May 14\, 2012 at 09​:06​:25AM -0700\, Linda W wrote​:

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators in a *slice* in the same way that could not also be used as reasoning to disallow such interpretation in the places it is now allowed\, i.e. ${xx} or to left of "=>" ?

Yes\, because regardless of whether it might have been nice to have when perl was first designed\, perl has for years been interpreting those barewords as function calls​:

  sub foo { print "foo called\n"; 0 }   sub bar { print "bar called\n"; 0 }   @​h{foo\,bar};

  outputs

  foo called   bar called

If we changed it now it wouldn't be backwardly compatible.

-- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff.   -- Things That Never Happen in "Star Trek" #9

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Eric Brine wrote​:

On Mon\, May 14\, 2012 at 12​:06 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators

There's no "seperators"\, just a single expression.

Your suggestion would break this code​:

$ perl -E'sub f { "a"\, "b" } sub g { "c"\, "d" } my %h = map { $_ => $_ } "a".."z"; say @​h{f\, g};'

I said to come up with an example that also couldn't be used to argue against changing semantics of "=>" to be different than "\,"\, which\, if I am not mistaken\, was done only recently (within the past few years) when quotes became no longer required for barewords in curlies.

In above\, if I had​:

$ perl -E'sub f { "a"\, "b" } sub g { "c"\, "d" } my %h = map { $_ => $_ } "a".."z"; say @​h{f => g};'

Before that change\, then after that change was made\, the above code wouldn't work the same way.

So that change broke an almost identical example when it was made\, yet no one thought that was of sufficient importance to not do so.

So why should it be any different now? Other than "just because"...?

p5pRT commented 12 years ago

From @Hugmeir

On Mon\, May 14\, 2012 at 4​:26 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

** Eric Brine wrote​:

On Mon\, May 14\, 2012 at 12​:06 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org \perl\-diddler@&#8203;tlinx\.org wrote​:

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a **key** to a hash\, can you come up with a justification for not always treating barewords between separators

There's no "seperators"\, just a single expression.

Your suggestion would break this code​:

$ perl -E'sub f { "a"\, "b" } sub g { "c"\, "d" } my %h = map { $_ => $_ } "a".."z"; say @​h{f\, g};'

---- I said to come up with an example that also couldn't be used to argue against changing semantics of "=>" to be different than "\,"\, which\, if I am not mistaken\, was done only recently (within the past few years) when quotes became no longer required for barewords in curlies.

Nope. Been that way forever. Actually\, the 5.005 perlop says this​:

The => digraph is mostly just a synonym for the comma operator. It's useful for documenting arguments that come in pairs. As of release 5.001\, it also forces any word to the left of it to be interpreted as a string.

So\, since 1995 or so.

p5pRT commented 12 years ago

From @ikegami

On Mon\, May 14\, 2012 at 3​:26 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

** I said to come up with an example that also couldn't be used to argue against changing semantics of "=>" to be different than "\,"\, which\, if I am not mistaken\, was done only recently (within the past few years) when quotes became no longer required for barewords in curlies.

I did not reply to any such request\, and the semantics of "=>" are different than "\,"\, so your comment makes no sense.

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Dave Mitchell via RT wrote​:

Yes\, because regardless of whether it might have been nice to have when perl was first designed\, perl has for years been interpreting those barewords as function calls​:

sub foo \{ print "foo called\\n"; 0 \}
sub bar \{ print "bar called\\n"; 0 \}
@&#8203;h\{foo\,bar\};

outputs

foo called
bar called

If we changed it now it wouldn't be backwardly compatible.

  sub retrieve_user_name(){"sally}   my $p={retrieve_user_name => owner};

  Was changed when someone decided to go through and clean up the need for quotes in many places on hash keys.

  That wasn't backwards compatible. So Why is it that all these non backward compatible changes were doable -- but only got done half way -- and now it's not ok to make the language consistent.

  There have been many non-backward compat changes -- barewords used to give no warnings.. but now do -- that's not backwards compat.

  The idea that backwards compat is a deal breaker hasn't seemed to stop alot of changes -- so explain to me what's different...   Like in such an expression\, a warning would issued for non-decorated functions. (stage 1)\, then in next version\, a use 5.2.0 would default to those being statics without decorations...

Father Chrysostomos via RT wrote​:

It’s conceptually simpler the way it is​: bareword or expression. If it’s not a single bareword\, then it’s an expression parsed the same way expressions are parsed anywhere else.

So how does that fit in with my $a = {read=>1\,printf=>2}; That isn't a simple expression. Instead\, another special case was made for that format.

Seems like each format required a new special rule. If both of the special cases each required their own special rule\, then why is there an issue with a similar construct also having a special rule?

Seem hypocritical to call a an implementation that follows established precedent "not simple" -- one could just as easily see it as you asking for a new special rule to NOT do it the way it has been done before and break precedence.

p5pRT commented 12 years ago

From @doy

On Mon\, May 14\, 2012 at 12​:26​:36PM -0700\, Linda W wrote​:

Eric Brine wrote​:

On Mon\, May 14\, 2012 at 12​:06 PM\, Linda W \perl\-diddler@&#8203;tlinx\.org wrote​:

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators

There's no "seperators"\, just a single expression.

Your suggestion would break this code​:

$ perl -E'sub f { "a"\, "b" } sub g { "c"\, "d" } my %h = map { $_ => $_ } "a".."z"; say @​h{f\, g};'

---- I said to come up with an example that also couldn't be used to argue against changing semantics of "=>" to be different than "\,"\, which\, if I am not mistaken\, was done only recently (within the past few years) when quotes became no longer required for barewords in curlies.

These two changes were made in 5.001\, which is not anything resembling "recently".

-doy

p5pRT commented 12 years ago

From @doy

On Mon\, May 14\, 2012 at 12​:44​:45PM -0700\, Linda W wrote​:

Dave Mitchell via RT wrote​:

Yes\, because regardless of whether it might have been nice to have when perl was first designed\, perl has for years been interpreting those barewords as function calls​:

sub foo { print "foo called\n"; 0 } sub bar { print "bar called\n"; 0 } @​h{foo\,bar};

outputs

foo called bar called

If we changed it now it wouldn't be backwardly compatible. ---- sub retrieve_user_name(){"sally} my $p={retrieve_user_name => owner};

Was changed when someone decided to go through and clean up the need for quotes in many places on hash keys.

That wasn't backwards compatible. So Why is it that all these non backward compatible changes were doable -- but only got done half way -- and now it's not ok to make the language consistent.

Our policy on backwards-incompatible changes has evolved over the past 20 years.

There have been many non-backward compat changes -- barewords used to give no warnings.. but now do -- that's not backwards compat.

Don't know what you're referring to here.

The idea that backwards compat is a deal breaker hasn't seemed to stop alot of changes -- so explain to me what's different... Like in such an expression\, a warning would issued for non-decorated functions. (stage 1)\, then in next version\, a use 5.2.0 would default to those being statics without decorations...

We could certainly start a deprecation cycle for a change\, if it was thought to be an improvement to the language. Pointing at something and saying "well this other thing changed in a backwards-incompatible way\, why can't you do the same thing here?" isn't an argument.

Father Chrysostomos via RT wrote​:

It’s conceptually simpler the way it is​: bareword or expression. If it’s not a single bareword\, then it’s an expression parsed the same way expressions are parsed anywhere else.

So how does that fit in with my $a = {read=>1\,printf=>2}; That isn't a simple expression. Instead\, another special case was made for that format.

Seems like each format required a new special rule. If both of the special cases each required their own special rule\, then why is there an issue with a similar construct also having a special rule?

Seem hypocritical to call a an implementation that follows established precedent "not simple" -- one could just as easily see it as you asking for a new special rule to NOT do it the way it has been done before and break precedence.

This is not a special case at all.

  my $foo = {   a => 1\,   b => 2\,   };

is legal syntax (it autoquotes 'a' and 'b'\, rather than calling functions named 'a' or 'b')\, and this is the exact same syntax that is being used in $foo{a=>1\,b=>2}. This derives directly from the definition of the => operator. There is no special casing anything at all. If you think this is a reasonable change to make\, you will need to explain why adding a new special case where none currently exists will make things easier to use or understand.

-doy

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 12​:46​:17 2012\, LAWalsh wrote​:

Father Chrysostomos via RT wrote​:

It’s conceptually simpler the way it is​: bareword or expression. If it’s not a single bareword\, then it’s an expression parsed the same way expressions are parsed anywhere else.

So how does that fit in with my $a = {read=>1\,printf=>2}; That isn't a simple expression.

In that example\, it’s the => doing the quoting. It autoquotes a single identifier to its left\, just as a hash subscript quotes a single identifier between braces.

--

Father Chrysostomos

p5pRT commented 12 years ago

From tchrist@perl.com

Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote   on Mon\, 14 May 2012 14​:18​:44 BST​:

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

"Valid bareword" sounds a bit funny. In Perl\, a "bareword" is just an identifier token sufficiently ambiguous to be deemed illegal under strict subs\, and to be a literal string otherwise.

  $when{time} = date; # one bareword\, "date"   $when{date} = time; # no barewords at all

When autoquoted\, it is not a bareword. Is that perhaps what you meant by "valid bareword"?

There also are no barewords here​:

  $what{01234} = 56789; # set key "668" to 56789   $what{56_789} = 01_234; # set key "56789" to 668

--tom

p5pRT commented 12 years ago

From @shadowcat-mst

Given that the insides of {} for a non-notated identifier (i.e. a 'bareword') or more specifically\, a *key* to a hash\, can you come up with a justification for not always treating barewords between separators in a *slice* in the same way that could not also be used as reasoning to disallow such interpretation in the places it is now allowed\, i.e. ${xx} or to left of "=>" ?

Because I'm afraid you're rather misunderstanding the mechanisms involved.

  $foo{bar}

is autoquoting the bar part\, i.e. treating it as

  $foo{'bar'}

whereas in

  @​foo{bar\,baz\,quux}

you have three barewords\, and can't do the same trick - the test that's used for the single key case is "is this only\, and entirely a bareword" - a comma separated sequence of anything is simply a different beast.

So it's not so much a justification that's required here as a clarification of the fundamental mechanisms involved.

I'll be happy to explain it at more length if you can identify where in the documentation the explanation needs to go in order to ensure that it doesn't confuse people in future - so the question is\, do you value perl enough to join us in helping improve it\, or do you just want to argue? If the former I'll be honoured to help you get your first documentation patch accepted; if the latter\, I'd rather spend the time on people who do want to contribute\, I'm afraid.

-- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http​://shadowcat.co.uk/blog/matt-s-trout/ http​://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support\, training and consultancy packages could help your team.

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

tchrist1 via RT wrote​:

Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote on Mon\, 14 May 2012 14​:18​:44 BST​:

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

"Valid bareword" sounds a bit funny. In Perl\, a "bareword" is just an identifier token sufficiently ambiguous to be deemed illegal under strict subs\, and to be a literal string otherwise.

  Yes\, you're right\, I'm being a bit redundant.

  As to others​: I didn't know =>'s differences went back that far. Trouble is I read up on things in major releases\, then tiny changes get put in in minor releases that I miss.

 
  Is sounds like it's impossible for anyone to think of a way to do this in perl. Oh well. I often set my expectations high -- I get disappointed alot too... ;-0

p5pRT commented 12 years ago

From @shadowcat-mst

On Mon\, May 14\, 2012 at 02​:02​:17PM -0600\, Tom Christiansen wrote​:

Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote on Mon\, 14 May 2012 14​:18​:44 BST​:

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

"Valid bareword" sounds a bit funny. In Perl\, a "bareword" is just an identifier token sufficiently ambiguous to be deemed illegal under strict subs\, and to be a literal string otherwise.

$when\{time\} = date;        \# one bareword\, "date"
$when\{date\} = time;        \# no barewords at all

When autoquoted\, it is not a bareword. Is that perhaps what you meant by "valid bareword"?

There also are no barewords here​:

$what\{01234\}  = 56789;     \# set key "668"   to 56789
$what\{56\_789\} = 01\_234;    \# set key "56789" to   668

I believe the documentation says "simple identifier" and I keep completely failing to use the correct term because perl never complains about simple identifiers at me but when I use one in the wrong place it screams about barewords.

So\, yes\, please read "simple identifier" where I say "bareword" in my previous missives and I'll endeavour to break myself of that bad habit in future writings.

Thanks for reminding me.

-- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http​://shadowcat.co.uk/blog/matt-s-trout/ http​://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support\, training and consultancy packages could help your team.

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 13​:02​:58 2012\, tom christiansen wrote​:

Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote on Mon\, 14 May 2012 14​:18​:44 BST​:

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

"Valid bareword" sounds a bit funny. In Perl\, a "bareword" is just an identifier token sufficiently ambiguous to be deemed illegal under strict subs\, and to be a literal string otherwise.

$when\{time\} = date;        \# one bareword\, "date"
$when\{date\} = time;        \# no barewords at all

When autoquoted\, it is not a bareword. Is that perhaps what you meant by "valid bareword"?

If we are to be that strict in our use of the term\, then this documentation for require from perlfunc needs to be corrected\, as require does its own autoquoting\, and goes even further than => by allowing double colons as well​:

If EXPR is a bareword\, the require assumes a "F\<.pm>" extension and replaces "F\<​::>" with "F\</>" in the filename for you\, to make it easy to load standard modules. This form of loading of modules does not risk altering your namespace.

In other words\, if you try this​:

  require Foo​::Bar; # a splendid bareword

The require function will actually look for the "F\<Foo/Bar.pm>" file in the directories specified in the C\<@​INC> array.

--

Father Chrysostomos

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 13​:11​:56 2012\, LAWalsh wrote​:

tchrist1 via RT wrote​:

Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote on Mon\, 14 May 2012 14​:18​:44 BST​:

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

"Valid bareword" sounds a bit funny. In Perl\, a "bareword" is just an identifier token sufficiently ambiguous to be deemed illegal under strict subs\, and to be a literal string otherwise.

---- Yes\, you're right\, I'm being a bit redundant.

As to others&#8203;: I didn't know =>'s differences went back that far\.

Trouble is I read up on things in major releases\, then tiny changes get put in in minor releases that I miss.

Is sounds like it's impossible for anyone to think of a way to do

this in perl. Oh well. I often set my expectations high -- I get disappointed alot too... ;-0

Don’t tell anyone I said this (oops! is this list public? :-)\, but you can omit the qw if you use angle brackets as the delimeter\, if you think qw is too ugly​:

$hash{\}

It’s actually using the glob operator\, which splits the pattern on spaces\, and returns each segment that contains no metacharacters unchanged.

I’ve even used it a few times myself. :-)

--

Father Chrysostomos

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 13​:46​:03 2012\, sprout wrote​:

On Mon May 14 13​:11​:56 2012\, LAWalsh wrote​:

tchrist1 via RT wrote​:

Matt S Trout \mst@&#8203;shadowcat\.co\.uk wrote on Mon\, 14 May 2012 14​:18​:44 BST​:

I'm not sure what you mean; as I mention above\, => is a comma that\, if its left hand side is a valid bareword\, implicitly quotes it.

"Valid bareword" sounds a bit funny. In Perl\, a "bareword" is just an identifier token sufficiently ambiguous to be deemed illegal under strict subs\, and to be a literal string otherwise.

---- Yes\, you're right\, I'm being a bit redundant.

As to others&#8203;: I didn't know =>'s differences went back that far\.

Trouble is I read up on things in major releases\, then tiny changes get put in in minor releases that I miss.

Is sounds like it's impossible for anyone to think of a way to do

this in perl. Oh well. I often set my expectations high -- I get disappointed alot too... ;-0

Don’t tell anyone I said this (oops! is this list public? :-)\, but you can omit the qw if you use angle brackets as the delimeter\, if you think qw is too ugly​:

$hash{\}

Er\, that should be @​hash{\}.

It’s actually using the glob operator\, which splits the pattern on spaces\, and returns each segment that contains no metacharacters unchanged.

I’ve even used it a few times myself. :-)

--

Father Chrysostomos

p5pRT commented 12 years ago

From @perhunter

On 05/14/2012 04​:46 PM\, Father Chrysostomos via RT wrote​:

\

Don’t tell anyone I said this (oops! is this list public? :-)\, but you can omit the qw if you use angle brackets as the delimeter\, if you think qw is too ugly​:

$hash{\}

It’s actually using the glob operator\, which splits the pattern on spaces\, and returns each segment that contains no metacharacters unchanged.

wouldn't that be really slow as glob has to read the dir to see if there are files with those names? maybe it won't as there are no metachars (i never use glob - read_dir from file​::slurp is my friend). also i think that would trigger pseudo multilevel hashes (using $; as the token separator) and i doubt that is wanted.

besides all this\, linda w seems to be wacko. not understanding => and wanting multiple token quoting? and how hard is qw() to type? jeez.

thanx\,

uri

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 14​:07​:44 2012\, uri@​stemsystems.com wrote​:

On 05/14/2012 04​:46 PM\, Father Chrysostomos via RT wrote​:

\

Don’t tell anyone I said this (oops! is this list public? :-)\, but you can omit the qw if you use angle brackets as the delimeter\, if you think qw is too ugly​:

$hash{\}

It’s actually using the glob operator\, which splits the pattern on spaces\, and returns each segment that contains no metacharacters unchanged.

wouldn't that be really slow as glob has to read the dir to see if there are files with those names? maybe it won't as there are no metachars

Your latter statement is correct. In fact\, in 5.16\, once File​::Glob is loaded\, glob should be about the same speed as split.

(i never use glob - read_dir from file​::slurp is my friend). also i think that would trigger pseudo multilevel hashes (using $; as the token separator) and i doubt that is wanted.

I meant @​hash{...}\, not $hash{...}.

besides all this\, linda w seems to be wacko. not understanding => and wanting multiple token quoting? and how hard is qw() to type? jeez.

Well @​hash{\} looks prettier than @​hash{qw\}\, doesn’t it?

--

Father Chrysostomos

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Father Chrysostomos via RT wrote​:

Don’t tell anyone I said this (oops! is this list public? :-)\, but you can omit the qw if you use angle brackets as the delimeter\, if you think qw is too ugly​:

$hash{\}

Er\, that should be @​hash{\}

Hey\, I'll take anything over what I have now... ;-)

(having RSI\, using alot of quotes really increases tiredness...)

p5pRT commented 12 years ago

From perl-diddler@tlinx.org

Father Chrysostomos via RT wrote​:

Well @​hash{\} looks prettier than @​hash{qw\}\, doesn’t it?

That's the trouble with so many engineers​: poor aesthetic sense! Functional? Good enough!... *sigh*\, at least some appreciate something beyond bare functionality.

p5pRT commented 12 years ago

From tchrist@perl.com

"Father Chrysostomos via RT" \perlbug\-followup@&#8203;perl\.org wrote   on Mon\, 14 May 2012 14​:34​:17 PDT​:

Well @​hash{\} looks prettier than @​hash{qw\}\, doesn't it?

Much prettier. I use it all the time\, too.

--tom

  package UCA;

  use v5.10.1;   use strict;   use warnings;

  use parent "Exporter";   our @​EXPORT = \<UCA{\,1\,2\,3\,4}>;

  use Unicode​::Collate;

  for my $strength ( 1 .. 4 ) {   no strict "refs";   *{ "UCA$strength" } = sub(_) {   state $coll = new Unicode​::Collate​::   level => $strength\,   variable => "Non-Ignorable"\,   ;   return $coll->getSortKey($_[0]);   };   }

  {   no warnings "once";   *UCA = \&UCA1;   }

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 15​:15​:22 2012\, tom christiansen wrote​:

"Father Chrysostomos via RT" \perlbug\-followup@&#8203;perl\.org wrote on Mon\, 14 May 2012 14​:34​:17 PDT​:

Well @​hash{\} looks prettier than @​hash{qw\}\, doesn't it?

Much prettier. I use it all the time\, too.

--tom

package UCA;

use v5\.10\.1;
use strict;
use warnings;

use parent "Exporter";
our @&#8203;EXPORT = \<UCA\{\,1\,2\,3\,4\}>;

Then I hope you will be pleased about this​:

$ time perl5.14.2 -e '@​_ = \<UCA{\,1\,2\,3\,4}> for 1..100000'

real 0m5.349s user 0m4.417s sys 0m0.916s

$ time perl5.16.0 -e '@​_ = \<UCA{\,1\,2\,3\,4}> for 1..100000'

real 0m3.228s user 0m2.364s sys 0m0.860s

--

Father Chrysostomos

p5pRT commented 12 years ago

From tchrist@perl.com

"Father Chrysostomos via RT" \perlbug\-followup@&#8203;perl\.org wrote   on Mon\, 14 May 2012 16​:26​:03 PDT​:

Then I hope you will be pleased about this​:

$ time perl5\.14\.2 \-e '@&#8203;\_ = \<UCA\{\,1\,2\,3\,4\}> for 1\.\.100000'

real    0m5\.349s
user    0m4\.417s
sys    0m0\.916s

$ time perl5\.16\.0 \-e '@&#8203;\_ = \<UCA\{\,1\,2\,3\,4\}> for 1\.\.100000'

real    0m3\.228s
user    0m2\.364s
sys    0m0\.860s

Certainly. Might you please hint how that was effected?

--tom

p5pRT commented 12 years ago

From @perhunter

On 05/14/2012 05​:34 PM\, Father Chrysostomos via RT wrote​:

On Mon May 14 14​:07​:44 2012\, uri@​stemsystems.com wrote​:

On 05/14/2012 04​:46 PM\, Father Chrysostomos via RT wrote​:

$hash{\}

It’s actually using the glob operator\, which splits the pattern on spaces\, and returns each segment that contains no metacharacters unchanged.

wouldn't that be really slow as glob has to read the dir to see if there are files with those names? maybe it won't as there are no metachars

Your latter statement is correct. In fact\, in 5.16\, once File​::Glob is loaded\, glob should be about the same speed as split.

makes sense.

  and how hard is qw() to type?

Well @​hash{\} looks prettier than @​hash{qw\}\, doesn’t it?

but not as clear to me and i bet others. qw is well understood. i would have to think for a bit to realize that was globbing and would return a list after spliting on whitespace. with qw\, i know that is happening. and i wouldn't use \<> with qw. i generally stick to ().

on a side note\, qw used to be converted to a split in the code by the compiler. i was helping port a large (and crappy :) codebase to 5.6 iirc. qw started to break in one place. seems they did string ops on the tokens from qw. when it was a split\, the strings were r/w so no problem. after the change in 5.6 to split at compile time\, they were ro tokens and the string op blew up. teaches them to not modify what looks like fixed string tokens. (actually this shop never learned anything from lessons like that).

uri

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 16​:28​:12 2012\, tom christiansen wrote​:

"Father Chrysostomos via RT" \perlbug\-followup@&#8203;perl\.org wrote on Mon\, 14 May 2012 16​:26​:03 PDT​:

Then I hope you will be pleased about this​:

$ time perl5\.14\.2 \-e '@&#8203;\_ = \<UCA\{\,1\,2\,3\,4\}> for 1\.\.100000'

real    0m5\.349s
user    0m4\.417s
sys    0m0\.916s

$ time perl5\.16\.0 \-e '@&#8203;\_ = \<UCA\{\,1\,2\,3\,4\}> for 1\.\.100000'

real    0m3\.228s
user    0m2\.364s
sys    0m0\.860s

Certainly. Might you please hint how that was effected?

To make a long story short\, File​::Glob​::csh_glob is now written in C\, rather than Perl.

--

Father Chrysostomos

p5pRT commented 12 years ago

From tchrist@perl.com

To make a long story short\, File​::Glob​::csh_glob is now written in C\, rather than Perl.

Really? I'd thought it had been in C since like forever.

--tom

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 17​:51​:59 2012\, tom christiansen wrote​:

To make a long story short\, File​::Glob​::csh_glob is now written in C\, rather than Perl.

Really? I'd thought it had been in C since like forever.

csh_glob is a wrapper around bsd_glob (which has always been written in C) that parses the pattern into separate tokens (when there are spaces) and takes care of iteration.

--

Father Chrysostomos

p5pRT commented 12 years ago

From tchrist@perl.com

"Father Chrysostomos via RT" \perlbug\-followup@&#8203;perl\.org wrote   on Mon\, 14 May 2012 17​:57​:11 PDT​:

Really? I'd thought it had been in C since like forever.

csh_glob is a wrapper around bsd_glob (which has always been written in C) that parses the pattern into separate tokens (when there are spaces) and takes care of iteration.

Ah\, that's it. I was thinking of bsd_glob.

--tom

p5pRT commented 12 years ago

From @iabyn

On Mon\, May 14\, 2012 at 01​:11​:09PM -0700\, Linda W wrote​:

As to others​: I didn't know =>'s differences went back that far. Trouble is I read up on things in major releases\, then tiny changes get put in in minor releases that I miss.

Except that changes that are documented in minor releases are also documented in the next major release too\, barring the occasional oversight.

(although prior to 5.004\, we didn't have perldelta.pod\, and the so the change documentation was a bit more haphazard.)

-- This is a great day for France!   -- Nixon at Charles De Gaulle's funeral

p5pRT commented 12 years ago

From @druud62

On 2012-05-14 22​:46\, Father Chrysostomos via RT wrote​:

Don’t tell anyone I said this (oops! is this list public? :-)\, but you can omit the qw if you use angle brackets as the delimeter\, if you think qw is too ugly​:

$hash{\}

It’s actually using the glob operator\, which splits the pattern on spaces\, and returns each segment that contains no metacharacters unchanged.

I’ve even used it a few times myself. :-)

I like to use it as well\, but be aware that many older perls go to the file system with this.

-- Ruud

p5pRT commented 12 years ago

From @cpansprout

On Mon May 14 06​:06​:04 2012\, rjbs wrote​:

I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0

Please do. :-)

--

Father Chrysostomos

p5pRT commented 12 years ago

From [Unknown Contact. See original ticket]

On Mon May 14 06​:06​:04 2012\, rjbs wrote​:

I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0

Please do. :-)

--

Father Chrysostomos