develooper Front page | perl.perl5.porters | Postings from July 2012

[perl #113684] Bleadperl v5.17.0-326-g6a31dbf breaks PJCJ/Devel-Cover-0.89.tar.gz

Father Chrysostomos via RT
July 26, 2012 09:09
[perl #113684] Bleadperl v5.17.0-326-g6a31dbf breaks PJCJ/Devel-Cover-0.89.tar.gz
Message ID:
On Sun Jul 22 09:38:49 2012, wrote:
> On Fri, Jul 13, 2012 at 08:16:47PM -0700, Father Chrysostomos via RT
> > On Sat Jun 16 18:49:49 2012, sprout wrote:
> > > I noticed through experimentation that loop exits (last, next)
have low
> > > precedence.  What I didn’t realise is that they have their own
> > > precedence level, unlisted in perlop:
> > > 
> > > diff --git a/pod/perlop.pod b/pod/perlop.pod
> > > index 3edeabd..c9a1adf 100644
> > > --- a/pod/perlop.pod
> > > +++ b/pod/perlop.pod
> > > @@ -49,6 +49,7 @@ values only, not array values.
> > >      nonassoc   ..  ...
> > >      right      ?:
> > >      right      = += -= *= etc.
> > > +    nonassoc   loop exits (last, next, goto)
> > >      left       , =>
> > >      nonassoc   list operators (rightward)
> > >      right      not
> > > 
> > > That could be considered a bug in perl.  In any case, I’d just muddied
> > > things a bit by trying to fix Deparse without realising what perl was
> > > actually doing.
> > > 
> > > Changing the precedence of goto might break it, as it takes an
> > > expression.  Other ‘loopexes’ are simply buggy when it comes to
> > > arbitrary expressions, treating anything that is not a simple constant
> > > as the empty label "".  But I think they should match goto (not
only in
> > > precedence, but in allowing computed labels).
> > 
> > Can we try to decide how this should work?  Should goto’s real
> > precedence be listed in perlop.pod?  Or should we fix its precedence? 
> > If the latter, which precedence shall it have?
> I'm probably not the right person to be opining on this, but I didn't
> want the thread to get lost, so here's my tuppence ha'penny worth.
> I can't see any reason why goto should have a different precedence level
> to last, next and so forth.  Is there one?  And in terms of elegance and
> aesthetics I think a shorter precedence table is preferable to a longer
> one.
> So should goto's precedence be changed to that of the other loop exits,
> or the other way around?  You seem to be leaning towards the latter,
> which would ensure there were no problems with C<goto expr>.  But I
> suspect the other loop exits are more common.
> You don't say where goto sits in the precedence table at the moment,

See the diff you quoted above. :-)

> but
> I'm assuming it's pretty close to the other loop exits.  Why do you
> think they should have the same precedence as goto?  Lacking your
> understanding, I'd imagine it should be the other way around.

Perhaps I wasn’t clear.  goto and last *do* have the same precedence. 
But last ignores (swallows up) any non-constant argument.  I was
suggesting making them conform in both respects, not just in precedence.

I placed the precedence just below assignment when trying to describe
the current behaviour, because this makes $a=$b the argument to goto:

goto $a = $b;

but this just makes $a the argument:

goto $a, $b;

However, since goto is a prefix (not infix) op, and since assignment is
right-associative, we could say that goto has the same precedence as
assignment, which amounts to the same thing.  This:

$a = goto $b = $c

means this:

$a = (goto ($b = $c))

> However, I'd also imagine any breakage from such changing of precedence
> (either way) to be minimal.  So once again we come to the question of
> whether the cost in backwards compatibility is worth the benefit.  In
> this case I would suspect the benefits of a simpler language to outweigh
> the backwards compatibility cost, but this is more of a gut feeling than
> an opinion backed by any evidence.

loopexes are the only named operators with assignment precedence, and I
was asking whether that should change.  But if it doesn’t need to add
any new entries to the precedence table, maybe it can stay as it is and
be documented that way.

Tangentially, I have also noticed that not() is listed with its own
precedence below list operators:

    nonassoc	list operators (rightward)
    right	not
    left	and

But, seeing it is a prefix op just like the other list ops, I don’t see
how the theoretical difference in precedence between not() and push()
can make any actual difference.  Am I missing something?  The parser
itself has separate rules for not(), but I think they could be
eliminated, simplifying the parser without changing observable behaviour.


Father Chrysostomos

via perlbug:  queue: perl5 status: open Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About