develooper Front page | perl.perl5.porters | Postings from November 2014

[perl #123092] Sub inlining inconsistencies

Thread Previous | Thread Next
Father Chrysostomos via RT
November 4, 2014 00:16
[perl #123092] Sub inlining inconsistencies
Message ID:
On Sun Nov 02 23:11:05 2014, demerphq wrote:
> On 2 November 2014 15:16, Father Chrysostomos via RT <
>> wrote:
> > On Sun Nov 02 00:30:58 2014, demerphq wrote:
> > > IOW, I think you are trying to solve this problem the wrong way. Don't
> > > bother fixing it, make it unnecessary to do at all.
> >
> > Also, there are cases where a sub containing two variables is mistakenly
> > deemed eligible for inlining, and then the wrong variable is used (or perl
> > crashes).  I think those cases should definitely be fixed.  But I don’t
> > know where to draw the line between ‘definitely’ and fixes that you don’t
> > deem necessary.
> >
> Fixing this so it doesnt "blow up" is IMO fine.
> All I am saying is that it seems like you are working with a real edge case
> here in that (I believe that) not that many people make functions with no
> arguments, in comparison to people who make constants. If fixing the edge
> case means breaking existing code making constants then IMO it is not worth
> it.

The code currently doesn’t make sense, such that it will exhibit changes in behaviour due to changes elsewhere.  So I need to change this code anyway.

Currently this does not make foo into a constant sub, for obvious reasons:

    my $x = 43;
    BEGIN { *foo = sub () { $x } }

(If it’s not obvious, the sub is created before the assignment happens, so it would capture the undefined value if made constant.)

Changes to fix bugs relating to ref aliasing and also to foreach and state will cause that to start becoming constant, unless I also change the code that determines what becomes constant.

Changing code that doesn’t make sense in order to keep it behaving exactly the same way in all its edge cases, without fixing other bugs, is very hard to do.  I would much prefer to make sense of it to begin with.

> Which then says to me the right solution is to provide some other prototype
> which can solve the problem of creating argumentless subs without
> triggering the const behavior.

I can’t imagine what such a prototype would look like.

> And if you do that then you might as well also make a ":const"
> prototype/attribute whatever.

I think that’s a good idea regardless.


Father Chrysostomos

via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About