On Tue, Jun 06, 2006 at 02:06:05AM +0100, Jonathan Worthington wrote: : "Sage La Torra" <sagelt@gmail.com> wrote: : >I've got a design document detailing the first few translations I'll be : >handling, and I'd greatly appreciate feedback and advice. : > : I may be off base here, or in the alternate pointing out a corner case : that's of little significance, but: : : -Compound statements: if($foo eq "a" or $foo eq "b" or $foo eq "c") {...} : -> if $foo eq "a"|"b"|"c" {...} : : Is there an issue if $foo is tied here, in that (unless the a or b : condition match) $foo will be evaluated three times; for testing against a : junction is it feasible that the compiler can say "aha, I'll only evaluate : $foo once and test it three times"? Reading $foo may have some real world : visible effects and the semantics would change. The P6 spec may nail this : down, but I haven't time to go look (and I'll surely not have time before I : forgot this thought completely...) Yes, but I think the translator can assume that most scalar variables aren't tied, especially if there isn't a tie anywhere else in the file. Could have a user option to pessimize that, and it should probably be logged as one of the places the translator guessed. But unlimited tying is one of the problems with Perl 5 that Perl 6 is trying to control, so it's sort of natural that the translator would run into this here and there. Another minor difference is that "or" guarantees an ordered short-circuit while "|" may short-circuit in any order the compiler pleases. Again, unlikely to be a problem for the variable in the absence of ties, but if some of the value calculations that can blow up are guarded by "or" conditions, then you've got a problem. We'll definitely need to provide some knobs for the user to turn to control how much refactoring is attempted. LarryThread Previous | Thread Next