develooper Front page | perl.perl5.porters | Postings from October 2017

Re: announcing a new op, OP_MULTICONCAT

Thread Previous | Thread Next
October 29, 2017 10:23
Re: announcing a new op, OP_MULTICONCAT
Message ID:
On 26 Oct 2017 09:42, "Dave Mitchell" <> wrote:

On Wed, Oct 25, 2017 at 11:48:23PM -0000, Father Chrysostomos wrote:
> Dave Mitchell wrote:
> > On Wed, Oct 25, 2017 at 03:40:15PM -0000, Father Chrysostomos wrote:
> > > If FETCH on a tied $x returns different values each time, does it con-
> > > tinue to behave the same way as currently?
> >
> > Yes - if a RHS arg is tied, it calls FETCH() for each appearance, and
> > makes a separate mortal copy of each result.
> Oh good.  You seem to be anticipating my devilish attempts to find
> problems with your optimizations. :-)

I've tried very hard to be bug-for-bug compatible with existing behaviour.
See for example this code comment in pp_multiconcat()!

    /* special-case $tied .= $tied.
     * For something like
     *    sub FETCH { $i++ }
     * then
     *    $tied .= $tied . $tied . $tied;
     * will STORE "4123"
     * while
     *    $tied .= $tied
     * will STORE "12"
     * i.e. for a single mutator concat, the LHS is
     * retrieved first; in all other cases it is
     * retrieved last. Whether this is sane behaviour
     * is open to debate; but for now, multiconcat (as
     * it is an optimisation) tries to reproduce
     * existing behaviour.

But no doubt there will be a whole bunch of things I didn't anticipate,
and I look forward to the inevitable slew of BBC tickets.

But wouldn't we consider this a bug we should fix?

 $x.= EXPR;

Should be the same as

$x = $x . EXPR;

If someone filed a bug report about this is would have thought we would
consider it fixable, even if maybe it shouldn't be fixed right away as part
of this patch.


Should be equivalent to

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