Front page | perl.perl5.porters |
Postings from July 2010
On Tue, Jul 20, 2010 at 01:12:29PM -0700, Jan Dubois wrote: > On Fri, 16 Jul 2010, hv@crypt.org wrote: > > Dave Mitchell <davem@iabyn.com> wrote: > > :However, for my opinions for the topic in hand... > > : > > :as regards tiedness, there are actually two orthogonal issues of > > :correctness. The first is which order in which the two $a's in $a.$a are > > :evaluated; the second is how many times $a is evaluated. It is quite > > :possible for the order not to be defined, but still for the fact that $a > > :is evaluated twice to be defined. For example, someone might be using tie > > :to instrument the number of accesses to a variable. > > > > This agrees with my thinking - I do not care a jot about the order of > > evaluation for this case, but I would be unhappy about any change to > > the number of times magic is invoked unless there were first strong > > evidence presented that substantial improvements (to speed or something > > else) would justify the change. > > Could you explain _why_ you would care about invoking magic twice, but > don't care about the order of evaluation? > > And could you also explain why it makes sense that $a.$a has to invoke > magic twice, while $a x 2 will only call it once? On this part, I believe that I agree with Hugo, because my answer is: I read $a . $a as equivalent to $x . $y, where it happens that $x and $y alias the same value. $a was *written* twice by the programmer, so as there are two references to it, it gets accessed *exactly* twice. Whereas $a x 2 has $a *written* once by the programmer, so as there is only one reference to it, it gets accessed *exactly* once. Basically, I view tie as active data, with an implied contract that it will be called once for each semantic read, and that this should be honoured. Hence I don't view $a . $a and $a x 2 as identical and interchangeable - if the programmer wanted the other, he/she should have written the other. Yes, this means that the compiler can't perform strength reduction or other optimisations in the general case. But I'm thinking of this from a perspective of "hooks exist to intercept the actions of the runtime" therefore the compiler isn't *allowed* to consider that transformations that are semantically valid for passive data are generally valid, because Perl *allows* active data. (Overload, on the other hand, I view as should-be-idempotent. I see its role as different. overload is expression of values. tie is a system to implement side effects) Nicholas ClarkThread Previous | Thread Next