On Friday 14 July 2006 00:30, Darren Duncan wrote: > This may go without saying, but ... > > If $a === $b means what I think it does, then I believe that a > not-premature implementation optimization of === would be that it > always $a := $b if it was returning true, so that any future === of > $a and $b or aliases thereof could short-circuit with a =:= test even > if they weren't created as aliases, and Perl would be automatically > more memory efficient without those extra storage copies. > > I know that was an implementation issue, but I think that it stands > to be explicitly stated anyway, as it is a very simple and effective > way to make Perl programs more resource efficient, possibly by orders > of magnitude, over not doing so.
First there was copy-on-write and now there's share-on-compare? > (The only time this may not work is if so-called immutable types are > tied to external resourses, but then I'm not sure how often this > would happen in practice so it could just be an exception if > necessary. The above-stated rule would still stand for any resources > managed by Perl itself.) In the absence of much Perl 6 code either way, I wonder at the value of adding such an extreme side effect to a simple comparison operation. This goes way beyond loop hoisting and constant folding. I can understand singleton value types (even Perl 5 does that with PL_undef), but ... wow, you have a lot more faith in local code analysis than I do. -- c
