develooper Front page | perl.perl5.porters | Postings from June 2013

[perl #24482] 5.8.2: sort CORE::keys() results in subroutine in sort

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
June 5, 2013 03:37
Subject:
[perl #24482] 5.8.2: sort CORE::keys() results in subroutine in sort
Message ID:
rt-3.6.HEAD-2552-1370403455-1890.24482-15-0@perl.org
On Sun Feb 03 05:45:38 2013, jkeenan wrote:
> On Sun Jan 27 17:42:43 2013, jkeenan wrote:
> > On Tue Jan 10 13:42:33 2012, sprout wrote:
> > > On Sun Nov 16 09:10:38 2003, rafael wrote:
> > > > James Jurach (via RT) wrote:
> > > > > 
> > > > >  $ perl -we '%a=(a=>"b"); print((sort CORE::keys(%a)),"\n")'
> > > > >  Undefined subroutine in sort at -e line 1.
> > > > > 
> > > > >  $ perl -we '%a=(a=>"b"); print((sort keys(%a)),"\n")'
> > > > >  a
> > > > 
> > > > This is due to two facts :
> > > > 
> > > > - perl will parse "sort foo(...)" and "sort(foo ...)" as "sort foo
> ..."
> > > >   In other words, it doesn't take the parens into account
> > > > - perl parses CORE::keyword as a subroutine, not as the
corresponding
> > > >   keyword.
> > > > 
> > > > Fixing this would probably break backward incompatibility in
> > > > undesirable ways.
> > > 
> > > How would that break compatibility?  Who is currently putting custom
> > > subroutines in the CORE:: namespace?
> > > 
> > 
> > There's been no correspondence in this ticket for a year.  Reviewing
> > this older ticket tonight, I don't see a strong case that there's a bug
> > in the source code which needs fixing.
> > 
> > Anyone disagree?  If not, I will close the ticket in seven days and am
> > taking it for that purpose.
> > 
> 
> No one spoke up to argue for the existence of a real bug.  Hence, I am
> closing this ticket as per schedule.  Marking ticket Rejected.

Actually, I think this *is* a bug, as CORE:: is supposed to disambiguate
and indicate a built-in keyword.

sort CORE::lc($_) should therefore do the same thing as sort lc($_), and
treat ‘CORE::lc’ as a keyword, rather than a sort sub name.

require happens to do the same thing as sort.  I consider this a bug,
too (the second one-liner should behave the same as the first):

$ ./perl -Ilib -e 'require lc "FOO.pl"'
Can't locate foo.pl in @INC (@INC contains: lib
/usr/local/lib/perl5/site_perl/5.19.1/darwin-2level
/usr/local/lib/perl5/site_perl/5.19.1
/usr/local/lib/perl5/5.19.1/darwin-2level /usr/local/lib/perl5/5.19.1 .)
at -e line 1.
$ ./perl -Ilib -e 'require CORE::lc "FOO.pl"'
String found where operator expected at -e line 1, near "require
CORE::lc "FOO.pl""
	(Do you need to predeclare require?)
syntax error at -e line 1, near "require CORE::lc "FOO.pl""
Execution of -e aborted due to compilation errors.

Fixing this is trivial.  Are there any objectors?

-- 

Father Chrysostomos


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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About