"no" not allowed in sort subroutine 
Author Message
 "no" not allowed in sort subroutine

[moderator please note, this post is being re-submitted after I discovered
our internal news server's moderated groups are broken.  I apologize for the
duplicates, if any--clinton]

This is more of a "why" question than anything else.  When I use the "no"
keyword inside of a sort BLOCK, perl responds with:

        "no" not allowed in expression at /tmp/foo.pl
        BEGIN not safe after errors--compilation aborted

For example in this largely nonsensical program:

use strict;  


Why doesn't this work?  Is the BLOCK for a sort a real block or no?  If I
move the 'no strict refs' pragma outside of the sort block, everythings
peachy.

What I'm really using this for is to allow someone to pick sort methods on
the fly in a CGI program.  A sample of the code follows (not all there):

#
# Sort subs
#
sub FREQ { $users{$a}->{count} <=> $users{$b}->{count} };
sub CDSID { $users{$a}->{cdsid} cmp $users{$b}->{cdsid} };
sub DATE { timelocal($users{$a}->{date}) <=> timelocal($users{$b}->{date})

Quote:
};

# And then later on...

        foreach my $user (
                sort {
                        no strict 'refs';   # This line doesn't work!
                        &{$cgi->param('FIRST')}
                                ||
                        &{$cgi->param('SECOND')}

                        } keys %users
                ) {
                # Do something with the data...
        }

Of course there's other ways around this, I'm just suprised that the sort
BLOCK is being treated like a second-class BLOCK.

--
   Clinton A. Pierce       "If you rush a Miracle Man, you

http://www.*-*-*.com/                       The Princess Bride



Sat, 27 Apr 2002 03:00:00 GMT  
 "no" not allowed in sort subroutine

Quote:

>This is more of a "why" question than anything else.  When I use the "no"
>keyword inside of a sort BLOCK, perl responds with:

>    "no" not allowed in expression at /tmp/foo.pl
>    BEGIN not safe after errors--compilation aborted

>For example in this largely nonsensical program:

>use strict;  


>Why doesn't this work?  Is the BLOCK for a sort a real block or no?  If I
>move the 'no strict refs' pragma outside of the sort block, everythings
>peachy.

This is one of the many anomalies (features? bugs?) caused by the
heuristics used by the lexer to decide if {} is a block or an
anonymous hash.    You can force Perl to think "block" in the standard
way by starting with a semicolon:


Yes -- I know it's not pretty, but ...

Mike Guy



Sat, 27 Apr 2002 03:00:00 GMT  
 "no" not allowed in sort subroutine

Quote:
> This is one of the many anomalies (features? bugs?) caused by the
> heuristics used by the lexer to decide if {} is a block or an
> anonymous hash.

I can understand the lexer being confused in other circumstances, but when
it's expecting a sort block, there's no room for doubt. If I understood
the lexer, I'd be submitting a patch here instead of merely copying the
Perl development team. Oh, well!

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



Sat, 27 Apr 2002 03:00:00 GMT  
 "no" not allowed in sort subroutine


Quote:
> .... If I understood
>the lexer, I'd be submitting a patch here instead of merely copying the
>Perl development team. Oh, well!

It may be that neither is necessary. Of the two versions of Perl
that just happen to be under my fingers right now, 5.004_04 exhibits
the mis-behaviour you report, but 5.005_54 works just fine. That's not
to say some later release hasn't reverted, of course.

[Oh, yes, of course, incidentally "correcting" the the example to read -

use strict;  


]

--

Computing Service        Phone:  +44 1223 334710
Cambridge University



Mon, 29 Apr 2002 03:00:00 GMT  
 "no" not allowed in sort subroutine

Quote:

>It may be that neither is necessary. Of the two versions of Perl
>that just happen to be under my fingers right now, 5.004_04 exhibits
>the mis-behaviour you report, but 5.005_54 works just fine. That's not
>to say some later release hasn't reverted, of course.

Alas, the lastest developer release (5.005_62) has reverted to
reporting:

"no" not allowed in expression at - line 3, at end of line
BEGIN not safe after errors--compilation aborted at - line 3.

Hmmmmm.... I'm somewhat unhappy with the second error message.
I know what it means, but I think a lot of people would be
wondering what "BEGIN" perl is complaining about.

-- HansM



Tue, 30 Apr 2002 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Can I build an index for a calculated field?

2. Apache/Perl "Method Not Allowed" error

3. Bareword "new" not allowed

4. "Not" not

5. Automating DB linkup with ReportSmith reports

6. "character class ""bug""

7. Q: "shift" in subroutine parameters

8. How to execute "deferred subroutines"?

9. "Demand-Compiling" Subroutines

10. Setuid and "Undefined subroutine"

11. scope subroutine argument with "our"

12. "Deep recursion on subroutine" error

 

 
Powered by phpBB® Forum Software