Re^4: A list assignment gotcha (Updated)

[jcb]

Great work by both of you, and the possible syntax tricks nicely show TIMTOWTDI, but the original motive for trying LIST += LIST was a hoped-for performance gain from the interpreter completing the whole set in one opcode, instead of add...add...add....

I suspect that overloaded objects like this will cause problems if used in inner loops. :-) Neat tricks, though...

[LanX]

> will cause problems if used in inner loops

performance won't be great unless implemented in XS.

But that's the way I would implement new features in Perl.

• a nice syntactic sugar which does the job in pure Perl and stays fully backwards compatible.
• speed it up in XS for newer versions
• if it becomes popular, consider including it into CORE.

[jcb]

Even with an XS implementation, you will still have the dispatch overhead for the overloaded operator. Eventually including it in core perl would allow the parser to resolve the dispatch at compile-time, but until then I wonder how long the list needs to be to make up that difference?

[LanX]

First of all choroba's code can be easily sped up by replacing the ->new with a direct bless

Syntax is rarely about speed otherwise you would do it right away in assembler.

In this particular example speed ups could be implemented if multiple operations happen

Something like

speed { L ($x, $y) * 3 + [5,6] + L (@z) };

wouldn't even need XS to be efficient, the objects inside the block would return optimized Perl code which is eval'ed only once and then reexecuted inside an inner loop.

With Keyword::Simple° even the overhead of calling speed could be avoided by inlining the code at compile-time.

°) which has an XS dependency but only needs Perl to be used.