Front page | perl.perl5.porters |
Postings from January 2011
Abigail <abigail <at> abigail.be> writes: >>>[cases where evaluating ($b + 0) changes the value of a later expression] >>changing ($b + 0) so that it just looks at the value of $b, but >>doesn't alter it, > >The problem with ($b + 0) is that it *cannot* just look at the value of >$b, if all that $b contains is a string. While you can in Perl, you cannot >add strings and integers in the underlaying machinery. And you aren't >seriously suggesting that: > > $b = "foo"; > $a = $b + 0; > say $a; > >should print "foo", are you? No, not at all. I don't suggest any change to the existing semantics of +, except that it should become side-effect-free, that is, whether you evaluate ($b + 0) or do not evaluate that expression should have no effect on later uses of $b. (Provided $b is just a plain scalar and not tied or an object, etc.) I suggest this partly out of a feeling that the existing behaviour, which you kindly pointed out, is not really a deliberate language design choice but just an unhappy side effect of an implementation decision. You are probably right that changing it would be a bigger task than it first appears. Obviously, one could remove the caching of numeric values altogether, letting them be recalculated every time. But the performance impact would be too much for most Perl users to accept just to fix some technical language bug. The ideal would be to keep the caching for speed but mark it somehow as 'this is just a cached value from use in numeric context; it should not change the underlying semantics of this scalar', and as you say, that would require an extra bit of storage somewhere. Anyway, this is not a bug I have discovered (if it accepted as a bug at all). You knew about it but haven't considered it to be a major issue. So I will have to say that unless one of the perl5 core developers thinks it worthy of their time, or I take a few days' holiday to look at it myself, the subject must rest here. -- Ed Avis <eda@waniasset.com> -- Ed Avis <eda@waniasset.com>Thread Previous | Thread Next