Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

[perl #112914] suppress warning on using unquoted strings in {} in slices too

  

 
First page Previous page 1 2 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded


perlbug-followup at perl

May 13, 2012, 2:53 PM

Post #1 of 46 (434 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too
# New Ticket Created by Linda Walsh
# Please include the string: [perl #112914]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112914 >



This is a bug report for perl from perl-diddler [at] tlinx,
generated with the help of perlbug 1.39 running under perl 5.14.2.


-----------------------------------------------------------------
[Please describe your issue here]

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.



[Please do not change anything below this line]
-----------------------------------------------------------------
---
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


perlbug-followup at perl

May 13, 2012, 5:49 PM

Post #2 of 46 (431 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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:

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

-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


---
via perlbug: queue: perl5 status: new
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112914


pagaltzis at gmx

May 14, 2012, 1:34 AM

Post #3 of 46 (429 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
* Father Chrysostomos via RT <perlbug-followup [at] perl> [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:

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

-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


perl-diddler at tlinx

May 14, 2012, 2:27 AM

Post #4 of 46 (429 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
A. Pagaltzis via RT wrote:
> * Father Chrysostomos via RT <perlbug-followup [at] perl> [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?


mailinglisten at renee-baecker

May 14, 2012, 3:17 AM

Post #5 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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.


mailinglisten at renee-baecker

May 14, 2012, 3:19 AM

Post #6 of 46 (429 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On 14.05.2012 12:17, Rene Bcker 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.


perlbug-comment at perl

May 14, 2012, 6:06 AM

Post #7 of 46 (428 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0


perlbug-comment at perl

May 14, 2012, 6:06 AM

Post #8 of 46 (428 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
I have applied the change Aristotle suggested as 5db45c0 and will apply it in 5.17.0


mst at shadowcat

May 14, 2012, 6:18 AM

Post #9 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
> 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.


h.m.brand at xs4all

May 14, 2012, 6:37 AM

Post #10 of 46 (433 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On Mon, 14 May 2012 14:18:44 +0100, Matt S Trout <mst [at] shadowcat>
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/


perlbug-followup at perl

May 14, 2012, 8:47 AM

Post #11 of 46 (428 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On Mon May 14 06:19:31 2012, mst [at] shadowcat 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


---
via perlbug: queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112914


ikegami at adaelis

May 14, 2012, 8:51 AM

Post #12 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On Mon, May 14, 2012 at 5:27 AM, Linda W <perl-diddler [at] tlinx> 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.


perl-diddler at tlinx

May 14, 2012, 9:06 AM

Post #13 of 46 (426 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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")


ikegami at adaelis

May 14, 2012, 9:38 AM

Post #14 of 46 (429 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On Mon, May 14, 2012 at 12:06 PM, Linda W <perl-diddler [at] tlinx> 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


perlbug-followup at perl

May 14, 2012, 9:46 AM

Post #15 of 46 (430 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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


---
via perlbug: queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112914


davem at iabyn

May 14, 2012, 9:58 AM

Post #16 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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


perl-diddler at tlinx

May 14, 2012, 12:26 PM

Post #17 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
Eric Brine wrote:
> On Mon, May 14, 2012 at 12:06 PM, Linda W <perl-diddler [at] tlinx> 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"...?


fraserbn at gmail

May 14, 2012, 12:37 PM

Post #18 of 46 (426 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On Mon, May 14, 2012 at 4:26 PM, Linda W <perl-diddler [at] tlinx> wrote:

> **
> Eric Brine wrote:
>
> On Mon, May 14, 2012 at 12:06 PM, Linda W <perl-diddler [at] tlinx> <perl-diddler [at] tlinx> 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.


ikegami at adaelis

May 14, 2012, 12:40 PM

Post #19 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
On Mon, May 14, 2012 at 3:26 PM, Linda W <perl-diddler [at] tlinx> 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.


doy at tozt

May 14, 2012, 12:43 PM

Post #20 of 46 (426 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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 [at] tlinx> 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


perl-diddler at tlinx

May 14, 2012, 12:44 PM

Post #21 of 46 (429 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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.

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.


doy at tozt

May 14, 2012, 12:52 PM

Post #22 of 46 (429 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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


perlbug-followup at perl

May 14, 2012, 12:55 PM

Post #23 of 46 (430 views)
Permalink
[perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
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


---
via perlbug: queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112914


tchrist at perl

May 14, 2012, 1:02 PM

Post #24 of 46 (428 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
Matt S Trout <mst [at] shadowcat> 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


mst at shadowcat

May 14, 2012, 1:02 PM

Post #25 of 46 (427 views)
Permalink
Re: [perl #112914] suppress warning on using unquoted strings in {} in slices too [In reply to]
> 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.

First page Previous page 1 2 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.