develooper Front page | perl.perl5.porters | Postings from August 2010

RE: Order of evaluation of terms (was peephole optimiser could prune more dead code)

Thread Previous | Thread Next
Jan Dubois
August 4, 2010 16:49
RE: Order of evaluation of terms (was peephole optimiser could prune more dead code)
Message ID:
On Wed, 04 Aug 2010, demerphq wrote:
> On 29 July 2010 18:23, Abigail <> wrote:
>> On Fri, Jul 16, 2010 at 12:18:48AM +0200, demerphq wrote:
>>> I agree, and I think that Jan's comment:
>>> <quote> My personal opinion is that any FETCH magic or overloaded
>>> operator that has observable side effects is essentially broken and
>>> abusing a feature. You can always use a function or method call if
>>> you need exact control over how your code is being called. </quote>
>>> should, after appropriate editing, be added to the documentation for
>>> tie as well.
>> I *strongly* disagree with this sentiment.
>> Part of the appeal of a tied variable is that you can throw it at a
>> piece of code you do not control (or do not want to change).
>> Saying one could just replace uses with a function or method call
>> would have been a great argument when the tieing mechanism was first
>> introduced - but we're way past this point now.
> IMO this is FUD.
> This is about ties with observable side effects. Not about using ties at all.

I don't think it is FUD, but I consider it wishful thinking.
Abigail already found 14 test cases where his assumption doesn't
hold, and I'm sure there are plenty more (I already posted one
earlier in this thread, that is not covered by his new tests).

It will be very hard to get the core to call FETCH only once per
"logical access" to a variable, and it will be *impossible* to get this
right for most CPAN modules containing XS code. You are lucky if XS code
gets magic handling right to begin with, but to make sure you never call
FETCH more than once is really hard, given that it may be called as a
side effect of some other operation (like using SvIV(sv), which may call
sv_2iv(), which may call FETCH magic).

It will also be almost impossible to write comprehensive tests for this
behavior, even just for the core, as we will not only have to cover all
code paths, but all code paths with all the different combinations of
flags on each SV. For example the number of FETCH calls for ++ is 2 if
the sv is SvNOK, but not SvIOK, but only 1 in most other cases.

So while we could strive to come as close as possible to the ideal of
calling FETCH only once per logical access, we should still warn users
that having a FETCH with side effects *is* very brittle in Perl and
should be avoided.


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